Re: Triggers on columns

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.

-- 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