From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | desmodemone <desmodemone(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, l(dot)denardo(at)miriade(dot)it, f(dot)dalmaso(at)miriade(dot)it |
Subject: | Re: BUG or strange behaviour of update on primary key |
Date: | 2011-10-18 03:41:35 |
Message-ID: | 1318909295.4197.3.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On tis, 2011-10-18 at 01:30 +0200, desmodemone wrote:
>
> alter table testup DROP CONSTRAINT testup_pkey ;
>
> alter table testup add primary key(a) DEFERRABLE INITIALLY
> IMMEDIATE ;
>
> update testup set a=a+1 ;
> UPDATE 2
>
> commit;
>
>
> Seems an Oracle bug not Postgresql one!
Oracle's behavior is OK. PostgreSQL's default behavior is wrong in the
sense that it checks the constraint even in invisible states *during*
the statement, rather than only after. Marking the constraint
DEFERRABLE (which means deferrable to the end of the *transaction*, not
statement) is a red herring to get the system to do it right(er),
because there is no separate syntax to say deferrable to end of
statement.
Basically, this is maintaining historical buggy behavior for
performance. If you want correct and slow behavior instead, you need to
tell explicitly.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-10-18 03:45:05 | Re: [v9.2] make_greater_string() does not return a string in some cases |
Previous Message | Tom Lane | 2011-10-18 03:24:15 | Re: BUG or strange behaviour of update on primary key |