Thread: Is TG_NARGS/TG_ARGV just legacy, or what?
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? -- --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
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 <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