Re: disallow LOCK on a view - the Tom Lane remix
От | Alfred Perlstein |
---|---|
Тема | Re: disallow LOCK on a view - the Tom Lane remix |
Дата | |
Msg-id | 20000829220510.K18862@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: disallow LOCK on a view - the Tom Lane remix (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [000829 20:52] wrote: > 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. > 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
В списке pgsql-hackers по дате отправления: