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 по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: disallow LOCK on a view - the Tom Lane remix
Следующее
От: Mark Hollomon
Дата:
Сообщение: Re: disallow LOCK on a view - the Tom Lane remix