Re: [HACKERS] disallow LOCK on a view - the Tom Lane remix

Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> * Mark Hollomon <mhh(at)mindspring(dot)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