Re: Implementing SQL ASSERTION

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implementing SQL ASSERTION
Date: 2018-01-15 12:10:36
Message-ID: alpine.DEB.2.20.1801151023320.3539@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Joe,

Just a reaction to the example, which is maybe addressed in the patch
which I have not investigated.

> * certain combinations of aggregates with comparison operations cannot
> be invalidating.
> As an example of the last point, the expression "CHECK (10 > (SELECT
> COUNT(*) FROM t))" cannot be invalidated by a delete or an update but
> can be invalidated by an insert.

I'm wondering about the effect of MVVC on this: if the check is performed
when the INSERT is done, concurrent inserting transactions would count the
current status which would be ok, but on commit all concurrent inserts
would be there and the count could not be ok anymore?

Maybe if the check was deferred, but this is not currently possible with
pg (eg the select can simply be put in a function), and I there might be
race conditions. ISTM that such a check would imply non trivial locking to
be okay, it is not just a matter of deciding whether to invoke the check
or not.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2018-01-15 12:28:02 Re: proposal: alternative psql commands quit and exit
Previous Message Robert Haas 2018-01-15 12:09:40 Re: [HACKERS] UPDATE of partition key