Itagaki Takahiro <[email protected]> writes:
> Peter Eisentraut <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
