Re: Revised Patch to allow multiple table locks in "Unison"

Tom Lane wrote:
>
> Fernando Nasser <fnasser@cygnus.com> writes:
> > What about having the syntax
> > LOCK a,b,c;
> > now just as a shorthand for
> > LOCK a;
> > LOCK b;
> > LOCK c;
> > This would save typing and allow for Oracle compatibility.
>
> This seems fine to me (and in fact I thought we'd already agreed to it).
> Maybe some day we will get ambitious enough to make it do
> parallel-locking, but for now we can get 80% of what we want with 0.8%
> of the effort ;-)
>

Agreed.

> > I wonder how we handle
> > LOCK v;
> > where "v" is a view.
>
> regression=# create view v as select * from int4_tbl;
> CREATE
> regression=# lock table v;
> ERROR:  LOCK TABLE: v is not a table
>
> > We should be locking all the base tables.
>
> I consider that debatable.  It hard-wires a rather constricted idea
> of what the semantics of a view are.
>

I've only mentioned it because it is what Oracle does.  It says explicitly
(in their documentation) that if "table" is "LOCK VIEW table" is actually
a view, all base tables necessary to compute that view are locked.

I guess the principle (for Oracle folks) was that, for the user, there should
be no distinction between a real table and a view. Thus, it should not matter
for the user if the thing that is being locked is a real table or if it
is actually being implemented as a view.  Consider that it may have been
a table one day, but the DBA changed it into a view.  So that SQL will
not work anymore and give the "ERROR:  LOCK TABLE: v is not a table" message.
This violates the Data Independence notion.



--
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9