Re: [HACKERS] Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date
Msg-id 38BB0D28.79B06301@tm.ee
Whole thread Raw
In response to Re: [HACKERS] Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: ALTER TABLE DROP COLUMN  (wieck@debis.com (Jan Wieck))
Re: [HACKERS] Re: ALTER TABLE DROP COLUMN  (Don Baccus <dhogaza@pacifier.com>)
List pgsql-hackers
Don Baccus wrote:
> 
> At 10:20 AM 2/28/00 -0500, Tom Lane wrote:
> >Don Baccus <dhogaza@pacifier.com> writes:
> >>> "update t set id=id+1" is also a 2x space,
> >
> >> And PG doesn't do it correctly anyway...
> >
> >? News to me.  What's your definition of "correctly"?
> 
> create table foo(i integer unique);
> 
> (insert values)
> 
> donb=# select * from foo;
>  i
> ---
>  1
>  2
>  3
> (3 rows)
> 
> donb=# update foo set i=i+1;
> ERROR:  Cannot insert a duplicate key into unique index foo_pkey

I knew it used to misbehave that way, but at some point I got the 
impression that it was fixed ;(

IIRC, the same behaviour plagued the old foreign key implementation 
in contrib, which was why it was refused for a long time to be 
integrated.

I hope that at least the foreig keys don't do it anymore.

---------
Hannu


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] having and union in v7beta