Tom Lane wrote:
> Phil Endecott <spam_from_postgresql_general@chezphil.org> writes:
>
>>It seems less scary when you think of metadata as just being the content
>>of more tables, rather than something special.
>
>
> PG does just fine with handling metadata changes transactionally.
> However, most operations that affect a table's schema at all will take
> an exclusive lock on the table, thereby blocking out other operations
> on the table until the schema-altering operation commits. This could be
> pretty annoying if you have lots of concurrent activity that needs to
> keep going --- in particular the proposed approach would lock out access
> to the underlying table for as long as it takes to update the
> materialized view, since the DROP TRIGGER would take that exclusive lock
> and it'd be held till end of transaction. If that's OK then there's
> nothing wrong with doing it that way.
Hi Tom,
I was hoping that my positive-sounding message would flush out any
problems...
I would understand this if I were doing an "ALTER TABLE", for example.
But does adding or removing a trigger really count as "schema-altering"?
--Phil.
