I can confirm that this is fixed in 7.0, I believe by Tom Lane.
> This was reported as a bug with the Debian package of 6.3.2; the same
> behaviour is still present in 6.4.
>
> bray=> create table foo ( t text[]);
> CREATE
> bray=> insert into foo values ( '{"a"}');
> INSERT 201354 1
> bray=>
This bug appears to still exist in 7.0:
test=> create table test (zone int4, net cidr, unique(zone, net));
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_zone_key'
for table 'test'
CREATE
test=> insert into test (zone, net) values (1,
This is Vadim's comment on the bug.
> Frank Cusack wrote:
> >
> > Solaris 2.6/sparc; postgres 6.5.1
> >
> > dns=> create table test (zone int4, net cidr, unique(zone, net));
> > NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_zone_key' for table
>'test'
> > CREATE
> > dns=> inse
Seems we don't support int8 sequences. Should we? I don't see a good
use for them.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
Bruce Momjian <[EMAIL PROTECTED]> 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
tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems we don't support int8 sequences. Should we? I don't see a good
> use for them.
Sooner or later we'll probably want to offer an option to make OID be
8 bytes. I could see switching sequences to int8 as well when we
do that. Of course it would n
