Re: [PATCH] SQL assertions prototype

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: [PATCH] SQL assertions prototype
Дата
Msg-id 20131125195047.GD6563@fetter.org
обсуждение исходный текст
Ответ на Re: [PATCH] SQL assertions prototype  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: [PATCH] SQL assertions prototype  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
On Mon, Nov 25, 2013 at 11:04:23AM -0800, Kevin Grittner wrote:
> Andrew Tipton <andrew@kiwidrew.com> wrote:
> > Simon Riggs <simon@2ndquadrant.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.
> 
> It does.
> 
> > 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.
> 
> That would certainly be a viable way to implement this once we have
> incremental maintenance for materialized views, although I make no
> claims to having evaluated it versus the alternatives to be able to
> assert what the *best* way is.
> 
> > No need to invent some sort of "get access to the changed
> > rows" mechanism especially for CREATE ASSERTION.
> 
> As soon as we are out of this CF, I am planning to write code to
> capture deltas and fire functions to process them "eagerly" (within
> the creating transaction).  There has been suggestions that the
> changeset mechanism should be used for that, which I will look
> into; but my gut feel is that it will be better to build a
> tuplestore of tids flagged with "old" or "new" around the point
> that "after triggers" fire.  How close does that sound to what
> CREATE ASSERTION (as currently envisioned) would need?

It sounds *extremely* close to what we'd need for row access in
per-statement triggers, as in probably identical.  The SQL syntax of
this sub-feature is described in Foundation section 11.49 and called
REFERENCING in CREATE TRIGGER.

Do you have any prototypes I could use for that purpose?

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [PATCH] SQL assertions prototype
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: [PATCH] SQL assertions prototype