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

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [000829 20:52] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)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