Re: Implementing SQL ASSERTION

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

In response to

Browse pgsql-hackers by date

  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