[kea-dev] pg specific data types for network addresses

[Marcin Siodelski]

Hello Matt,

I don't think there are any particular issues with using the dedicated 
macaddress and inet types to represent lease data. In early Kea days we 
first implemented the MySQL lease backend. Since MySQL didn't have these 
special types, we used an integer to represent the lease address and 
varbinary for the MAC address. When we later added the PostgreSQL 
backend, we wanted to keep the parity between the two backends and their 
code base similar. At some point we even had ideas to unify the code of 
the two backends. IIRC, this is one of the reasons why we also used 
simple types in Postgres.

Additionally, we thought that using privimite types minimizes the 
chances of any performance problems related to indexing, writing and 
querying the columns with these specialized data types. I don't have any 
evidence that an INET type is "slower" than the INT but one would think 
that INT should typically be faster because it is "simpler". It can be 
wrong but better safe than sorry.

Finally, we haven't had use cases in DHCPv4 that would justify the usage 
of these specialized types.

While there is no big issue with using these specialized data types, 
we'd now need a good justification for migrating. Lease table is a heart 
of the DHCP system and there are many deployments using the current 
format. Migrating away is a big risk of breaking various 
instrumentations people have for lease databases.

Kind Regards,

Marcin Siodelski
Sr. Software Engineer
ISC

On 6.09.2023 03:01, Matt Zagrabelny wrote:
> Greetings Kea-dev,
> 
> Looking at the git repo for kea, I see some traction for using Pg's inet 
> data type in the src/share/database/scripts/pgsql/dhcpdb_create.pgsql. 
> However, the lease4 table uses a bigint for the IP address and a bytea 
> for the MAC address.
> 
> Are there plans to migrate to Pg's native types of inet and macaddr for 
> these fields?
> 
> Have you considered this course and found technical reasons to not use 
> those data types?
> 
> Thanks for the info!
> 
> -m
>