Re: [PATCH] SQL assertions prototype

From: Andrew Tipton <andrew(at)kiwidrew(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] SQL assertions prototype
Date: 2013-11-24 17:42:52
Message-ID: CA+M2pVVT3_szvtkMKR-ViA1r4Xo5C-0URuGwL8BN47KmS-5Exg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 24, 2013 at 11:03 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> So we'd need to get access to the changed rows, rather than
> re-executing a huge SQL command that re-checks every row of the table.
> That last point will make it unusable for sensible amounts of data.

That sounds very similar to handling incremental maintenance of
materialized views, which Kevin is working on.

Let's assume that the "huge SQL command that re-checks every row of
the table" is actually a materialized view. In that case, the CREATE
ASSERTION trigger would merely need to scan the matview and raise an
error if any rows were present. That should be a very quick
operation. No need to invent some sort of "get access to the changed
rows" mechanism especially for CREATE ASSERTION.

Kind regards,
Andrew Tipton

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Tipton 2013-11-24 18:21:42 Re: Add CREATE support to event triggers
Previous Message Rodolfo Campero 2013-11-24 17:36:58 Re: PL/Python: domain over array support