Re: disallow LOCK on a view - the Tom Lane remix - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: disallow LOCK on a view - the Tom Lane remix
Date
Msg-id 20000829220510.K18862@fw.wintelcom.net
Whole thread Raw
In response to Re: disallow LOCK on a view - the Tom Lane remix  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [000829 20:52] wrote:
> Alfred Perlstein <bright@wintelcom.net> writes:
> > Ok, I'm wondering if this patch will cause problems locking a table
> > that has had:
> > CREATE RULE "_RETfoo" AS ON SELECT TO foo DO INSTEAD SELECT * FROM foo1;
> > I need to be able to lock the table 'foo' exclusively while I swap
> > out the underlying rule to forward to another table.
>
> Uh, do you actually need any sort of lock for that?
>
> Seems to me that if you do
>     BEGIN;
>     DELETE RULE "_RETfoo";
>     CREATE RULE "_RETfoo" AS ...;
>     COMMIT;
> then any other transaction will see either the old rule definition
> or the new one.  No intermediate state, no need for a lock as such.
>

Ugh!  I keep on forgetting that transactions are atomic.  Thanks.

> BTW, this seems to be a counterexample for my prior suggestion that
> pg_class should have a "relviewrule" OID column.  If it did, you'd
> have to update that field when doing something like the above.
> Pain-in-the-neck factor looms large...

I'd prefer this stuff be as simple as possible, it's already
getting quite complex.

thanks,
-Alfred

pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: new in list
Next
From: Jan Wieck
Date:
Subject: Re: Backend-internal SPI operations