Re: On view updating

Alfredo Novoa wrote:
> On Tue, 21 Sep 2004 13:05:03 -0700, Costin Cozianu
> <c_cozianu_at_hotmail.com> wrote:
>
>

>>There's no such thing as "virtual variables" in PL theory.

Oh, yes. A user can know that even trivially.   SELECT OBJECT_TYPE FROM USER_OBJECTS WHERE OBJECT_NAME='XXX' In the theory of imperative PL the type associated with an expression indicates whether it can be used as l-value or not.

A proper relational database would give you away the fact that it is a view by simply typing it correctly

typeof('XXX') => RelationType
typeof('YYY') => REF RelationType

> BTW PL theory is not closed and we can introduce "virtual variables"
> and even weirder things.
>

You could if you knew what you were doing.

>

>>- views do not denote a "store".

Because.

>>as opposed to views, tables, which also have a name:
>>
>>- denote a "store". A place in the global state holding a value that can
>>be changed.

I do not think you know anymore what you are talking about.

> Do you consider closed views as tables?
>
>

>>Therefore, here you have your trivial distinction in all imperative
>>languages between a "store" (variable, possibly aliased or non-aliased)
>>which is your lvalue, and an expression.

Yes you can have aliases, and you can have views. They're different things.

An alias is typed as reference to a relation type. A view is typed as the relation type itself.

> If something looks like a variable, smells like a variable and behaves
> like a variable then it is a variable :)
>

No, it doesn't behave like a variable and that's the whole point.You are presupposing the conclusion and pretend to have something.

In order to prove your point you'd have to come up with a formal semantics for a SQL or Tutorial D database in which a '''formal''' mechanism for dealing with the state update can treat views and tables the same way.

You don't have that, Date doesn't have that, McGoveran doesn't have that. Their attempt to shoehorn view updates into the model suffer all the problems that we've talked about, and buys us precious little.

As opposed to that most PL language theory when it comes to imperative features has this elementary and useful distinction:

• value types and reference types are distinct

(l-values are distinct from r-values)

In ML you have
  val x= ref 1

or
  val y = 1

x can be updated (it refers to a store that is initialized with integer 1) where y cannot be.

The same thing happens even in C.
You can write

int x;
scanf("%d",&x);

To read an integer from standard input into the store refered to by the variable x,
but you cannot write

scanf("%d",&(x+1));
because (x+1) is an expression, it does not reference a store.

Therefore you have in imperative languages two categories * stores
* expressions

When you say CREATE TABLE you create a store, you define the type of the values stored in that place.

When you say CREATE VIEW you create an expression and you give it a name. The fact that the expression can be *at a limit*

        (select * from table)
does not make it less of an expression. You do not have a useful semantics that can map *any* expression to a store.

Therefore updatability of views cannot be viewed as a general mechanism in the model but rather as a synctactic shorthand that deals with special cases by translating them to real updates of real tables. But nothing more than the special cases is warranted.

Costin Received on Thu Sep 23 2004 - 16:54:12 CEST