[ still poking around in this patch ] Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers