Re: [HACKERS] New IP address datatype

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, mvolpe(at)eos(dot)ncsu(dot)edu
Subject: Re: [HACKERS] New IP address datatype
Date: 1999-06-01 14:38:38
Message-ID: 199906011438.KAA24168@candle.pha.pa.us
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. :-)

OK, but let's make a decision.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-06-01 14:39:03 Re: [HACKERS] Release date and docs
Previous Message Bruce Momjian 1999-06-01 14:36:33 Re: [HACKERS] ALTER TABLE ADD COLUMN