From: | Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implementing SQL ASSERTION |
Date: | 2018-09-29 17:07:41 |
Message-ID: | 467051FC-B88B-4550-A1C8-AAA2076DF029@elusive.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David,
> On 26 Sep 2018, at 19:47, David Fetter <david(at)fetter(dot)org> wrote:
>
>> Invalidating operations are "INSERT(t) and UPDATE(t.b, t.n)".
>
> So would DELETE(t), assuming n can be negative.
Oops, right you are. Bug in my implementation :-)
> Is there some interesting and fairly easily documented subset of
> ASSERTIONs that wouldn't have the "can't prove" property?
We can certainly know at the time the ASSERTION is created if we
can use the transition table optimisation, as that relies upon
the expression being written in such a way that a key can be
derived for each expression.
We could warn or disallow the creation on that basis. Ceri & Widom
mention this actually in their papers, and their view is that most
real-world use cases do indeed allow themselves to be optimised
using the transition tables.
-Joe
From | Date | Subject | |
---|---|---|---|
Next Message | David Hedberg | 2018-09-29 17:50:49 | Re: Adding pipe support to pg_dump and pg_restore |
Previous Message | Andrew Dunstan | 2018-09-29 17:03:56 | Re: Cygwin linking rules |