[ still poking around in this patch ]
Jeff Davis <pgsql@j-davis.com> writes:
> 10. You're overloading tgconstrrelid to hold the constraint's index's
> oid, when normally it holds the referenced table. You should probably
> document this a little better, because I don't think that field is used
> to hold an index oid anywhere else.
Having documented this kluge doesn't make it any more acceptable. It
risks breaking any number of things that expect that field to reference
a table, not an index.
There seem to be two reasonable alternatives here:
* Add another column to pg_trigger (and hence the Trigger data
structure) to carry the index OID.
* Store the index OID as a trigger argument (which means converting it
to text form, and then back again for each use).
The former approach would be a lot easier if anyone is trying to query
pg_trigger for the triggers associated with an index, but OTOH I'm not
sure anyone would really need to do that. The latter approach minimizes
catalog changes at the cost of a bit of runtime inefficiency; but
considering everything else that goes on to fire a deferred trigger,
worrying about a strtoul call is probably silly.
If we did add another column to pg_trigger, I'd be a bit tempted to add
one to pg_constraint too. tgconstrrelid for RI triggers is a mirror of
a pg_constraint column, and it seems like the index data perhaps should
be as well. (Indeed, one of the thing that got me annoyed about this
kluge in the first place was that it broke that relationship without
changing the documentation.)
Comments, opinions?
regards, tom lane