Re: Call for Google Summer of Code mentors, admins
| От | Kevin Grittner |
|---|---|
| Тема | Re: Call for Google Summer of Code mentors, admins |
| Дата | |
| Msg-id | 1365525592.75858.YahooMailNeo@web162906.mail.bf1.yahoo.com обсуждение исходный текст |
| Ответ на | Re: Call for Google Summer of Code mentors, admins (David Fetter <david@fetter.org>) |
| Список | pgsql-advocacy |
David Fetter <david@fetter.org> wrote: > On Tue, Apr 09, 2013 at 10:22:20AM +0200, Dimitri Fontaine wrote: >> David Fetter <david@fetter.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
В списке pgsql-advocacy по дате отправления: