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