Re: Implementing SQL ASSERTION - Mailing list pgsql-hackers

From Joe Wildish
Subject Re: Implementing SQL ASSERTION
Date
Msg-id 467051FC-B88B-4550-A1C8-AAA2076DF029@elusive.cx
Whole thread Raw
In response to Re: Implementing SQL ASSERTION  (David Fetter <david@fetter.org>)
List pgsql-hackers
Hi David,

> On 26 Sep 2018, at 19:47, David Fetter <david@fetter.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




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Cygwin linking rules
Next
From: David Hedberg
Date:
Subject: Re: Adding pipe support to pg_dump and pg_restore