From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Triggers on columns |
Date: | 2009-10-05 00:14:50 |
Message-ID: | 20091005091151.9CD0.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-10-05 00:16:50 | Re: Rules: A Modest Proposal |
Previous Message | Stephen Frost | 2009-10-04 22:58:06 | Re: Rules: A Modest Proposal |