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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Mark Hollomon <mhh@mindspring.com>, pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org
Date: 2000-08-30T03:52:28Z
Lists: pgsql-hackers
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