Re: [HACKERS] Open 6.5 items

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
Subject: Re: [HACKERS] Open 6.5 items
Date: 1999-05-29 12:07:42
Message-ID: m10nhtu-0000bIC@druid.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thus spake Tom Lane
> "D'Arcy" "J.M." Cain <darcy(at)druid(dot)net> writes:
> > but we have to decide which of the following is true.
>
> > 198.68.123.0/24 < 198.68.123.0/27
> > 198.68.123.0/24 > 198.68.123.0/27
>
> I'd say the former, on the same principle that 'abc' < 'abcd'.

And, in fact, that's what happens if you use the operators. The only
place they are equal is when sorting them so they can't be used as
primary keys. I guess there is no argument about the sorting order
if we think they should be sorted. There is still the question of
whether or not they should be sorted. There seems to be tacit sgreement
but could we have a little more discussion. The question is, when inet
or cidr is used as the primary key on a table, should they be considered
equal. In fact, think about the question separately as we may want a
different behaviour for each. Here is my breakdown of the question.

For inet type, the value specifies primarily, I think, the host but
also carries information about its place on the network. Given an inet
type you can extract the host, broadcast, netmask and even the cidr
that it is part of. So, 198.68.123.0/24 and 198.68.123.0/27 really
refer to the same host but on different networks. Since a host can only
be on one network, there is an argument that they can't both be used
as the primary key in the same table.

A cidr type is primarily a network. In fact, some valid inet values
aren't even valid cidr. So, the question is, if one network is part
of another then should it be possible to have both as a primary key?

Of course, both of these beg the real question, should either of these
types be used as a primary key, but that is a database design question.

> Think of the addresses as being bit strings of the specified length,
> and compare them the same way character strings are compared.

Not sure that that clarifies it but we do have the code to order them
in any case. We just need to decide whether we want to.

> But if Vixie's got a different opinion, I defer to him...

Paul's code orders them without regard to netmask which implies "no"
as the answer to the question but his original code only referred to
what we eventually called the cidr type. The question would still
be open for the inet type anyway.

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-29 15:03:04 Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/storage/buffer bufmgr.c'
Previous Message Kaare Rasmussen 1999-05-29 06:38:15 Re: [HACKERS] Outer joins