Tom Lane <t...@sss.pgh.pa.us> writes: > FWIW, I agree with Thom on this. If we do it as you suggest, I > confidently predict that it will be less than a year before we seriously > regret it. Given all the discussion around this, it's borderline insane > to believe that the set of parameters to be passed to command triggers > is nailed down and won't need to change in the future. > > As for special coding of support, it hardly seems onerous when every > language that has triggers at all has got some provision for the > existing trigger parameters. A bit of copying and pasting should get > the job done.
So, for that to happen I need to add a new macro and use it in most call sites of CALLED_AS_TRIGGER(fcinfo). That includes the setup switch in src/pl/plpgsql/src/pl_comp.c doCompile() and plpgsql_call_handler() for starters. Let's call the macro CALLED_AS_COMMAND_TRIGGER(fcinfo), and I would extend CommandContextData to be a Node of type CommandTriggerData, that needs to be added to the NodeTag enum as T_CommandTriggerData. With that in place I can stuff the data into the function's call context (via InitFunctionCallInfoData) then edit the call handlers of included procedure languages until they are able to init their language variables with the info. Then, do we want the command trigger functions to return type trigger or another specific type? I guess we want to forbid registering any function as a command trigger? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
