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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alfred Perlstein <bright(at)wintelcom(dot)net>
Cc: Mark Hollomon <mhh(at)mindspring(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
Date: 2000-08-30 03:52:28
Message-ID: 17928.967607548@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-08-30 04:56:21 Re: new in list
Previous Message Mark Hollomon 2000-08-30 01:03:00 Re: disallow LOCK on a view - the Tom Lane remix

Browse pgsql-patches by date

  From Date Subject
Next Message Alfred Perlstein 2000-08-30 05:05:11 Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
Previous Message Mark Hollomon 2000-08-30 01:03:00 Re: disallow LOCK on a view - the Tom Lane remix