On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner <kgrittn@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).