Re: Triggers, again.. ;-)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Triggers, again.. ;-)
Date: 2005-02-22 16:51:48
Message-ID: 10399.1109091108@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andre Schnoor 2005-02-22 17:10:38 Simple client messages from within pgPL/SQL
Previous Message Phil Endecott 2005-02-22 16:31:21 Re: Triggers, again.. ;-)