Re: delta relations in AFTER triggers - Mailing list pgsql-hackers
From | Kevin Grittner |
---|---|
Subject | Re: delta relations in AFTER triggers |
Date | |
Msg-id | 1406561067.22267.YahooMailNeo@web122306.mail.ne1.yahoo.com Whole thread Raw |
In response to | Re: delta relations in AFTER triggers (Marti Raudsepp <marti@juffo.org>) |
Responses |
Re: delta relations in AFTER triggers
|
List | pgsql-hackers |
Marti Raudsepp <marti@juffo.org> wrote: > On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner <kgrittn@ymail.com> wrote: >> it seems to me that we need the full tuple to support triggers on >> FDWs, so the TID approach would be an optimization for a subset of >> the cases, and would probably be more appropriate, if we do it at >> all, in a follow-on patch >> If you disagree with that assessment, now would be a good >> time to explain your reasoning. > > Maybe I just have a limited imagination because I've never found a use > for FDWs personally. But recording changes from a trigger on a FDW > table doesn't seem that useful, It's a matter of whether AFTER triggers on an FDW can see the modified data in table form. We just recently added the ability for FDW triggers to see the data in *row* form; it seemed odd to immediately follow that with a new way to get at the data and cripple FDW triggers for it. > since you can only capture changes > done by the local node. I expect that in many situations there are > multiple writers accessing the same underlying remote table. Certainly > it's can't guarantee the consistency of materialized views. While I expect the techniques used here to help with development of incremental maintenance of materialized views, this seems like a useful feature in its own right. I think the question is what the basis would be for supporting access to the changes in row format but not table format for FDWs, if we're supporting both formats for other tables. >> I took a look at whether I could avoid making OLD and NEW >> non-reserved keywords, but I didn't see how to do that without >> making FOR at least partially reserved. If someone sees a way to >> do this without creating three new unreserved keywords >> (REFERENCING, OLD, and NEW) I'm all ears. > > Sorry, I know I am very late to make this point, so feel free to ignore this. > > I'm not a fan of the SQL standard syntax for this feature. One nice > thing about PostgreSQL's triggers is that you can declare the trigger > function once and re-use it on many tables. It would make more sense > if the same function declaration could say what variable/relation > names it wants to use. They're more like function argument names, not > some metadata about a table-function relationship. > > Putting these in the CREATE TRIGGER command means you have to repeat > them for each table you want to apply the trigger to. It introduces > the possibility of making more mistakes without any gain in > flexibility. > > But then again, I understand that there's value in supporting standard > syntax. Do you have some other suggestion? Keep in mind that it must allow the code which will *generate* the transition tables to know whether any of the attached triggers use a given transition table for the specific operation, regardless of the language of the trigger function. Using the standard syntax has the advantage of making it pretty easy to put the information exactly where it is needed for easy access at run time. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: