Re: [HACKERS] New IP address datatype - Mailing list pgsql-hackers

From D'Arcy" "J.M." Cain
Subject Re: [HACKERS] New IP address datatype
Date
Msg-id m10onNi-0000bIC@druid.net
Whole thread Raw
In response to Re: [HACKERS] New IP address datatype  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] New IP address datatype
List pgsql-hackers
Thus spake Tom Lane
> > Thus spake Mark Volpe
> >> Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
> >> display 134.67.131.10.
> 
> Hmm.  This suggests that the example given in the recent discussion
> about primary keys is bogus: 198.68.123.0/24 is never equal to
> 198.68.123.0/27, because they represent networks of different sizes.

I don't think it's so clear cut.  For INET, the two addresses refer
to the same host but contradict each other in network details.  The
INET type is primarily a host type with optional network information
added.  One might even argue that 198.68.123.1/24 and 198.68.123.2/27
should not be allowed to coexist but that's probably going too far.

For the CIDR type, they refer to two different networks but they overlap.
The argument is that as a primary key they partially conflict so they
shouldn't be allowed to coexist.

> If you were talking about host addresses, then the netmask would be
> /32 in both cases, and so the issue doesn't arise.

Right.  For the INET type the netbits defaults to /32 so it can be used
for hosts transparently.

> I'm back to the opinion that netmask does matter in comparisons and in
> indexes ... but I'd sure like to hear what Vixie has to say about it.

I have asked him.

> BTW, if we did want to make INET and CIDR have different behavior in
> comparisons and indexes, that would mean having two sets of operators
> listed in the system catalogs.  We cannot add that as a post-6.5 patch
> because it would require an initdb, which is one of the things we don't
> do between major releases.  If it's wrong (I'm not convinced) we must
> either fix it this week or live with it till 6.6 ...

At this point I doubt we want to start mucking with catalogues and new
operators.  Fixing it to be consistent is probably doable.

And since I will never use either type as a primary key, I can live
with either decision.  :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.


pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: Re: [HACKERS] LIMITS
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] pg_dump