Re: Batch API for After Triggers

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> On 8 June 2013 22:25, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:

> There are also difficulties in semantics, since when
> we have OLD and NEW at row level we know we are discussing the same
> row. With sets of OLD and NEW we'd need to be able to link the
> relations back together somehow, which couldn't be done by PK since
> that could change. So we'd need to invent some semantics for a
> "linking identifier" of some description. Which once we've done it
> would be used by people to join them back together again, which is
> what we already had in the first place. So my take is that it sounds
> expressive, but definitely not performant.

I have used a feature like this in other database products, and can
say from experience that these relations in a statement trigger can
be very useful without the linkage you propose.  I can see how the
linkage could potentially be useful, but if that is the only
hang-up, we would be adding a powerful feature without it.

> Since my objective is performance, not standards, I don't see a reason
> to work on that, yet. I might have time to work on it later, lets see.

This seems like it has some overlap with the delta relations I will
need to generate for incremental maintenance of materialized views,
so we should coordinate on those efforts if they happen to occur
around the same time.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company