Is TG_NARGS/TG_ARGV just legacy, or what?

Andrew,

It does have the advantage that you can call a single trigger function
with variable argument types/numbers. "Fixing" it would involve an
unknown amount of legacy breakage.

Yes ... I don't see a good way to maintain legacy compatibility.

Triggers seem like the least useful place to have variable-argument
functions, though. And it is inconsistent with how we use functions
everywhere else, as well as in violation of the SQL03 standard on CREATE
FUNCTION (don't know what the standard says about triggers, though).

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus said:

Folks,

I was just building something and noticing the peculiar structure we've
given to arguments to trigger procedures. Instead of declaring them
normally, we pass them through the variables TG_NARGS and TG_ARGV[].
This is inconsistent with the entire rest of Postgres, as well as
making it hard to validate passed constants (e.g. if you pass the
wrong number of arguments, you won't know it until execution time).

Is there some sound technical reason not to use the standard argument
declaration, or is this just something we've overlooked fixing?

I'm not sure it's broken ... just different.

It does have the advantage that you can call a single trigger function with
variable argument types/numbers. "Fixing" it would involve an unknown amount
of legacy breakage.

cheers

andrew

Josh Berkus <josh@agliodbs.com> writes:

Triggers seem like the least useful place to have variable-argument
functions, though. And it is inconsistent with how we use functions
everywhere else, as well as in violation of the SQL03 standard on CREATE
FUNCTION (don't know what the standard says about triggers, though).

On what basis do you assert that?

Triggers necessarily have arguments that aren't in the explicit argument
list, namely the state data about the new/old row and so on. It
wouldn't be productive to try to force all that stuff to be passed as
explicit arguments (and if we did try, we'd make it harder to add more
trigger arguments in future). The ARGV thing for stuff passed from the
CREATE TRIGGER command is certainly on the crufty side, but it's not
inconsistent with how we pass all the other data to a trigger. I don't
see an argument for changing this that justifies the compatibility
problems we'd create.

regards, tom lane