Re: Reducing lock strength of adding foreign keys

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