Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix |
Дата | |
Msg-id | 17928.967607548@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | disallow LOCK on a view - the Tom Lane remix (Mark Hollomon <mhh@mindspring.com>) |
Ответы |
Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix
Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix |
Список | 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 по дате отправления: