Itagaki Takahiro <itagaki.takah...@oss.ntt.co.jp> writes: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers