From: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Deferred constraint trigger semantics |
Date: | 2022-05-13 06:43:51 |
Message-ID: | 5F2AF0A2-DF85-42DF-A2C1-EBEB03E54F8F@yugabyte.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> laurenz(dot)albe(at)cybertec(dot)at wrote:
>
> Be "seeing" I didn't mean "show to the user". I mean that the code that implements PostgreSQL constraints takes uncommitted data into account.
>
> The documentation describes that for the case of uniqueness in some detail:
>
> https://www.postgresql.org/docs/current/index-unique-checks.html
>
> I'd say that the proper mental model is that you don't need to care. The ACID properties are guarantees that the database makes, and these guarantees are usually negative: "no sequence of actions can result in the violation of a unique constraint" or "you don't get to see uncommitted data".
>
> The exact sequence of what happens during COMMIT is interesting, but irrelevant to the programmer. All that counts is "a deferred constraint is checked between the time that COMMIT starts processing and the time that it returns".
>
> If you want to know more, you have to start reading the code. It is open source and well documented.
Thanks for the quick reply, Laurenz. I'm signing off now (US/Pacific) for a long weekend. I'll try to digest what you wrote on Monday.
From | Date | Subject | |
---|---|---|---|
Next Message | alias | 2022-05-13 10:47:00 | generated column cast from timestamptz to timestamp not OK. |
Previous Message | Bryn Llewellyn | 2022-05-13 06:37:39 | Re: Restricting user to see schema structure |