Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
Date
Msg-id 17928.967607548@sss.pgh.pa.us
Whole thread Raw
In response to disallow LOCK on a view - the Tom Lane remix  (Mark Hollomon <mhh@mindspring.com>)
Responses Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
List pgsql-patches
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.

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...

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
Next
From: "Ross J. Reedstrom"
Date:
Subject: Re: [HACKERS] when does CREATE VIEW not create a view?