Re: Implementing SQL ASSERTION - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Implementing SQL ASSERTION
Date
Msg-id alpine.DEB.2.20.1801151023320.3539@lancre
Whole thread Raw
In response to Re: Implementing SQL ASSERTION  (Joe Wildish <joe-postgresql.org@elusive.cx>)
Responses Re: Implementing SQL ASSERTION
List 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.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] UPDATE of partition key
Next
From: Laurenz Albe
Date:
Subject: Re: proposal: alternative psql commands quit and exit