From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> |
Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implementing SQL ASSERTION |
Date: | 2018-09-26 11:36:05 |
Message-ID: | 1532a20c-93dc-05f8-e179-1c7e316c4667@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 25/09/2018 01:04, Joe Wildish wrote:
> Having said all that: there are obviously going to be some expressions
> that cannot be proven to have no potential for invalidating the assertion
> truth. I guess this is the prime concern from a concurrency PoV?
Before we spend more time on this, I think we need to have at least a
plan for that. Perhaps we could should disallow cases that we can't
handle otherwise. But even that would need some analysis of which
practical cases we can and cannot handle, how we could extend support in
the future, etc.
In the meantime, I have committed parts of your gram.y changes that seem
to come up every time someone dusts off an assertions patch. Keep that
in mind when you rebase.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Keiichi Hirobe | 2018-09-26 12:04:51 | Re: [patch]overallocate memory for curly braces in array_out |
Previous Message | Fabien COELHO | 2018-09-26 11:23:44 | Re: Online verification of checksums |