> I can take care of putting the code into the main PostgreSQL system, but
> I need someone to give me a definitive cidr/ip type that I can
> integrate.
>
> People really want this for 6.4. We are in beta, but we can add this
> type IF we can get it integrated within the next week or ten days.
>
> When do you think you can you look over both versions, and send me one
> good version to work with?
>
> I can take it from there, and Paul and I can work out any bugs in the
> code.
>
> Even if you just say, "Paul's is better, throw out ip_and_mac", that is
> all we need.
i don't think it's that clear cut. my type is intended for layer 3
applications (IP) where either hosts or networks (or subnets including
variable-width subnets) need to be used as keys. the ip_and_mac type
is host-only but has an unfortunate bridging between layer 3 and layer 2.
in my opinion these are separate types, and since cidr is ready to go in
we ought to defer ip_and_mac to 6.5, and refocus it on layer 2 applications.
consider an ARP or DHCP table, which maps between layer 3 and layer 2.
having a type optimized for layer 3 and a different type optimized for
layer 2 creates no ugliness in my mind, and in fact serves the only need
i can imagine better than a single multihedral type would do.
note that cidr as supplied is capable of holding ipv6, which is also a
layer 3 entity. changing the name from CIDR to INET would be ok by me,
but making a type which is capable of holding either a layer 3 entity
or a layer 2 one would create semantic tension in my mind about it.
