Re: Triggers on columns

Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> Peter Eisentraut <peter_e@gmx.net> wrote:
>> OK, but what you can do is point both variants to the same C function
>> and check with PG_NARGS() with how many arguments you were called.  That
>> would save some of the indirections.

> The regressiontest 'opr_sanity' failed if do so. Should we remove this
> check only for pg_get_triggerdef? If we cannot do that, the first version
> of patch is still the best solution.

I have always been of the opinion that V1 functions should be written
in the style

foo(PG_FUNCTION_ARGS)
{type1    arg1 = PG_GETARG_whatever(0);type2    arg2 = PG_GETARG_whatever(1);type3    arg3 = PG_GETARG_whatever(2);

as much as possible.  The V1 protocol is already a big hit to
readability compared to plain-vanilla C functions, and one of the main
reasons is that you can't instantly see what arguments a function is
expecting.  Sticking to the above style ameliorates that.  Cute tricks
like conditionally grabbing arguments depending on PG_NARGS do far more
damage to readability than they can ever repay in any other metric.

In short: while I haven't looked at the patch, I think Peter may be
steering you in the wrong direction.

In cases where you do have related functions, I suggest having
SQL-callable V1 functions that absorb their arguments in this
style, and then have them call a common subroutine that's a plain
C function.
        regards, tom lane