Re: [HACKERS] New IP address datatype

From: "D'Arcy" "J(dot)M(dot)" Cain <darcy(at)druid(dot)net>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgresql(dot)org, mvolpe(at)eos(dot)ncsu(dot)edu
Subject: Re: [HACKERS] New IP address datatype
Date: 1999-06-01 12:10:58
Message-ID: m10onNi-0000bIC@druid.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at){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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-06-01 12:20:35 Re: [HACKERS] pg_dump
Previous Message Chris Bitmead 1999-06-01 11:22:48 Re: [HACKERS] LIMITS