2014-07-28 19:27 GMT+02:00 Marti Raudsepp <ma...@juffo.org>: > On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner <kgri...@ymail.com> wrote: > > 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. > > You will need to access the pg_proc record of the trigger function > anyway, so it's just a matter of coming up with syntax that makes > sense, right? > > What I had in mind was that we could re-use function argument > declaration syntax. For instance, use the "argmode" specifier to > declare OLD and NEW. Shouldn't cause grammar conflicts because the > current OUT and INOUT aren't reserved keywords. > > We could also re-use the refcursor type, which already has bindings in > some PLs, if that's not too much overhead. That would make the > behavior straightforward without introducing new constructs, plus you > can pass them around between functions. Though admittedly it's > annoying to integrate cursor results into queries. > > Something like: > > CREATE FUNCTION trig(OLD old_rows refcursor, NEW new_rows refcursor) > RETURNS trigger LANGUAGE plpgsql AS '...'; >
I dislike this proposal - it is strongly inconsistent with current trigger design Regards Pavel > > Or maybe if the grammar allows, we could spell out "NEW TABLE", "OLD > TABLE", but that's redundant since you can already deduce that from > the refcursor type. > > It could also be extended for different types, like tid[], and maybe > "record" for the FOR EACH ROW variant (dunno if that can be made to > work). > > 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 >
