On 10/28/2014 01:33 AM, Noah Misch wrote:
ALTER TRIGGER is not bad; like you say, change pg_get_triggerdef_worker() the way commit e5550d5 changed pg_get_constraintdef_worker(). DROP TRIGGER is more difficult. pg_constraint.tgqual of a dropped trigger may reference other dropped objects, which calls for equipping get_rule_expr() to use the transaction snapshot. That implicates quite a bit of ruleutils.c code.
I started looking into this again and fixed pg_get_constraintdef_worker() as suggested.
But I have no idea how to fix get_rule_expr() since it relies on doing lookups in the catcache. Replacing these with uncached lookups sounds like it could cause quite some slowdown. Any ideas?
Indexes should suffer from the same problems since they too have emay contain expressions but they seem to solve this by having a higher lock level on DROP INDEX, but I do wonder about the CONCURRENTLY case.
By the way, unless I am mistaken there is currently no protection against having a concurrent ALTER FUNCTION ... RENAME mess up what is dumped in by pg_get_triggerdef().
-- Andreas Karlsson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
