Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix

* 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