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

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

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(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."