From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Deferrable constraint execution not respecting "initially immediate"? |
Date: | 2017-07-11 22:02:59 |
Message-ID: | CAKFQuwb8oHS1zfdGOqYaWzrXAmduS-5zJ_iYbo54m3pEubpo1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Jul 10, 2017 at 10:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > From "CREATE TABLE":
> > "A constraint that is not deferrable will be checked immediately after
> > every command."
>
> > I think the above should be "after every row" instead of "after every
> > command".
>
> I believe that FK constraints work differently from indexes in this
> regard. Not sure that we want to get into that level of detail here.
>
Since three of the 4 types are done "after every row" if we want to
simplify (I'm leaning toward being precise here) I'd rather be imprecise
about the FK. Pretending that a FK change is checked sooner than it
really is seems like a minor omission since the observed behavior isn't
likely to be noticeable. Wondering why "update pk = pk + 1" doesn't work
by default when PK constraints are checked "after every command" has been
shown to be noticeable.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | 张明富 | 2017-07-12 10:56:54 | an error "duplicate key value violates unique constraint ..." happend when update table |
Previous Message | Bruno Richard | 2017-07-11 20:48:11 | Re: PostgreSQL hot standby Hangs due to AccessExclusiveLock on pg_attribute or pg_type tables |