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

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

> I had originally felt strongly that there should be only one datatype
> ... but IIRC the thread Peter referred to convinced me that they should
> indeed be two types, or at least that there's a darn good argument for
> that viewpoint. Michael, have you reviewed the archives? I'd be
> interested to hear your take on that discussion.
>
> Single basic datatype plus two domains seems like a reasonable approach
> if we feel that both viewpoints have merit. But I wonder whether they
> both do ...

Arguments for a single data type:

An address is an address, and it seems to be a waste to have
a column for IPv4 and one for IPv6, when the latter or the
former will nearly always be empty.

Parsing, text output, masklen(), show(), abbrev(), network(),
and host() all work identically on IPv4 or IPv6 addresses, and
return the proper data.

Arguments against a single data type:

lt(), gt(), cmp(), etc. all work fine when comparing the same
family, but get a little odd (that is, fail) when comparing
different families.

broadcast() really doesn't mean much on an IPv6 address.

The way I'm using the data types right now I tend to prefer one column
that can hold either type, so I don't have to worry about which is
which. I can use family() to make certain the families are compatible
when comparing them.

I've reviewed the archives on the topic, and tend to believe one
data type still makes sense. If the IPv6 support won't be accepted
unless changes are made, I will have to learn more about pgsql. The
last time I hacked on it was when it had the unfortunate name of
Postgres, about half a year before it became Postgres95 or something
like that. :)

Here's the latest patches, which now include documentation changes
(although they are likely rough) and regression tests (which caught a
bug or two, imagine that!)