Phil Endecott <spam_from_postgresql_general@xxxxxxxxxxxx> 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.
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
