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. -- Considering only built-in procs (prolang = 12), look for multiple uses -- of the same internal function (ie, matching prosrc fields). It's OK to -- have several entries with different pronames for the same internal function, -- but conflicts in the number of arguments and other critical items should -- be complained of. (We don't check data types here; see next query.) -- Note: ignore aggregate functions here, since they all point to the same -- dummy built-in function. oid | proname | oid | proname ! ------+-------------------+------+------------------- ! 1662 | pg_get_triggerdef | 2730 | pg_get_triggerdef ! (1 row) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
