On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner <kgri...@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, 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. > 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. Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers