Skip site navigation (1) Skip section navigation (2)

Re: uniqueness not always correct

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Frank Cusack <fcusack(at)iconnet(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: uniqueness not always correct
Date: 2000-06-01 02:13:07
Message-ID: 12455.959825587@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> This bug appears to still exist in 7.0:
> 	test=> create table test (zone int4, net cidr, unique(zone, net));

Yeah.  IIRC, the issue is that the CIDR data-type-specific btree
comparison function looks at all bits in the datatype, including bits
that are past the specified length (/24, here) and weren't necessarily
zeroed by the datatype input routine.  It's not clear whether the
comparator or the input routine or both are wrong --- *should* those
bits be significant, or not?

The discussion about how to fix it bogged down, and apparently
no one did anything.  I recall feeling that we had some confusion
between what the semantics of CIDR and INET types ought to be,
but I don't understand them well enough to know what they should do.
Right now the same operators are used for both, which seems like it
can't be right.

I was hoping someone would dig through the archives or talk to Paul
Vixie again and come away with a clear understanding of the semantics
of these two datatypes (and why we need two, if we do).

Alternatively, if no one cares enough about these types to even
understand what they should do, maybe we should rip 'em out?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-01 02:26:12
Subject: Re: pg_am.amowner
Previous:From: Bruce MomjianDate: 2000-06-01 01:28:20
Subject: Re: more cvs problems

pgsql-bugs by date

Next:From: Tom LaneDate: 2000-06-01 02:19:01
Subject: Re: Bug in Create sequence parsing?
Previous:From: Bruce MomjianDate: 2000-06-01 01:21:07
Subject: Re: Bug in Create sequence parsing?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group