Re: IPv6 address parsing for inet/cidr types (take II)

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> As I recall, Paul Vixie's first attempt at this was rejected because it
> undid a lot of painfully-arrived-at decisions about the I/O behavior of
> these datatypes. You need to tell us exactly what you did about those
> issues. (No, I don't have time to read the code to find out...)

It shouldn't change the behavior much at all -- all I do is
return a different data length for ipv6 addresses (16 bytes rather
than 4) but the inet and cidr behavior remain unchanged, as well as
the on-disk storage model for ipv4 addresses. ipv6 uses a different
family type.

> You also need to supply some documentation updates --- code updates
> alone are incomplete. I'd not have had to ask the question above if
> this patch included proper documentation. The "Network Address Data
> Types" and "Network Address Type Functions" pages both need to be fixed.
>
> Some additions to the inet regression test would seem in order, too.

I'd gladly do those, but wanted feedback on the work in progress
before I did them. Paul asked me to mail out what I had asap, and
I've not made the documentation or regression test changes yet
(although I have the regression tests for my own use, of course.)

One other poster suggested they should be two data types, which I half
agree with. There are advantages of being able to use IPv4 or IPv6
addresses in the same column, so I wouldn't have to have two tables
for host <-> address mappings, for instance. I'm undecided on which
is better, but so far I've used the inet with ipv4 and 6 data type
once and found them useful under one data type.

--Michael