Re: Deferred constraint trigger semantics - Mailing list pgsql-general

From Bryn Llewellyn
Subject Re: Deferred constraint trigger semantics
Date
Msg-id 5F2AF0A2-DF85-42DF-A2C1-EBEB03E54F8F@yugabyte.com
Whole thread Raw
In response to Re: Deferred constraint trigger semantics  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general
laurenz.albe@cybertec.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.

pgsql-general by date:

Previous
From: Bryn Llewellyn
Date:
Subject: Re: Restricting user to see schema structure
Next
From: alias
Date:
Subject: generated column cast from timestamptz to timestamp not OK.