Re: Call for Google Summer of Code mentors, admins

David Fetter <david(at)fetter(dot)org> wrote:
> On Tue, Apr 09, 2013 at 10:22:20AM +0200, Dimitri Fontaine wrote:
>> David Fetter <david(at)fetter(dot)org> writes:

>>>>> UPDATE ... RETURNING OLD

>>> There are several more DML operations with odd inability to
>>> return rows, but UPDATE's the one that really stands out, and
>>> is a bite-sized chunk in the sense of having a relatively small
>>> scope of design and not touching parts of the system unless
>>> they use the new grammar.
>>
>> Which makes me think about having OLD and NEW "relations"
>> available in per statement triggers, too. Would that be a SoC
>> sized projects? Maybe if the relation is simply a SRF…
>
> Are you envisioning this as a common infrastructure to both?

This may also wind up sharing some infrastructure with incremental
mainenance of materialized views.  The most efficient and provably
correct optimization of that I've found in the literature[1] seems
to me to require the ability to accumulate "delta relations", and
it has been occuring to me how easy it would be to use a delta
relation for a statement to supply the OLD and NEW relations for an
FOR EACH STATEMENT trigger.

I don't really want to get into a design discussion about
incremental maintenance of matviews at this time, but felt that I
should give a "heads up" about potentially overlapping work.

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

[1]  http://dl.acm.org/citation.cfm?id=170066&dl=ACM&coll=DL&CFID=202507837&CFTOKEN=96875563