Re: disallow LOCK on a view - the Tom Lane remix
От | Tom Lane |
---|---|
Тема | Re: disallow LOCK on a view - the Tom Lane remix |
Дата | |
Msg-id | 13911.967589921@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: disallow LOCK on a view - the Tom Lane remix (Alfred Perlstein <bright@wintelcom.net>) |
Список | pgsql-hackers |
Alfred Perlstein <bright@wintelcom.net> writes: > * Mark Hollomon <mhh@mindspring.com> [000829 11:26] wrote: >> Here is a patch against CVS (without my earlier patch) >> to disallow >> LOCK x >> if x is a view. > Waitasec, why?? This can be very useful if you want to atomically lock > something that sits "in front" of several other tables that you need to > do something atomically with. > Does it cause corruption if allowed? No, but I doubt that it does anything useful either ... the system is going to be acquiring locks on the referenced tables, not the view itself. A full (exclusive) LOCK on the view itself might work (by preventing other backends from reading the view definition), but lesser types of locks would certainly not operate as desired. Even an exclusive lock wouldn't prevent re-execution of previously planned queries against the view, as could happen in plpgsql functions for example. Moreover, a lock on the view would not prevent people from accessing/manipulating the referenced tables; they'd just have to not go through the view. All in all, the behavior seems squirrelly enough that I agree with Mark: better to consider it a disallowed operation than to have to deal with complaints that it didn't do whatever the user thought it would do. regards, tom lane
В списке pgsql-hackers по дате отправления: