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