Re: BUG or strange behaviour of update on primary key

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.

In response to

Browse pgsql-hackers by date

  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