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

* Tom Lane <tgl@sss.pgh.pa.us> [000829 15:58] wrote:
> 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.

This is a bug that could be solved with a sequence of callbacks
hooked to a relation that are called when that relation changes.

> 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.

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.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."