Re: more on delete from join

From: Kevin Kirkpatrick <kvnkrkptrck_at_gmail.com>
Date: Fri, 28 Aug 2009 20:39:02 -0700 (PDT)
Message-ID: <c1d987c5-bfea-4c31-a97a-7271c08a3869_at_d21g2000vbm.googlegroups.com>


On Aug 28, 6:29 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Kevin Kirkpatrick wrote:
> > On Aug 28, 4:32 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
> >>Kevin Kirkpatrick wrote:
>
> >>...
>
> >>>>By the way, why assume that CURRENT_USER
> >>>>is not updateable?
>
> >>>Great question, cuts to the heart of the matter:  It can't be updated
> >>>because it is a view.  It returns an conclusion, and it is not (IMO)
> >>>valid to assert conclusions. ...
>
> >>So A UNION B is a conclusion when assigned to a view, but not a
> >>conclusion when assigned to a base.  Where does this idea come from and
> >>what is it good for, apart from appearing to be a spurious reason to say
> >>that views aren't updateable?  Even if I were to accept that views
> >>aren't updateable, I'd ask why is CURRENT_USER necessarily a view?
>
> >>(Personally, I would prefer an engine that allows a user to log himself
> >>off by means of a simple delete rather than the usual arcane engine
> >>plumbing that introduces various environmental commands.  That way, the
> >>environment is forced to react to db changes rather than the other way
> >>around.  The engine becomes much simpler if this approach is followed
> >>and this is important if there's ever to be any progess in the aspects
> >>that today's engines slough off.)
> >>...
>
> > My point, phrased another way, is: given base relvars A, B, and C with
> > identical headings, this does not make sense:
>
> > (A UNION B) := (B UNION C)
>
> > in the exact same way that this does not make sense:
>
> > int x, y;
> > x+y := 3;
>
> But computers do solve systems of equations:
>
> x+y = 3
> x-y = 1

Well, I will grant that. But there is an difference between

exp[0]:='x+y = 3'
exp[1]:='x-y = 1'
print(Solve_system (exp, 'x')); -- prints 2

and
x+y := 3;
x-y := 1;
print (x); -- prints 2? (does it? can it? see below...)

To see why these must be treated differently, consider:

exp[0] := 'x=4'
exp[1] := 'x=5'
print(Solve_system (exp, 'x')); -- error!

vs.

x:=4;
x:=5; -- no error
print(x); -- prints 5 (of course)

I simply still see no hole in the following line of reasoning: 1) A query is a value. Its value is of type "valid query" - a string that can be evaluated by the DBMS (returning a relation value). 2) Views are variables that hold values of type 'valid query'. 3) The only sense by which views can be updated is in the sense that their values of type "valid query" can be modified. Below are some valid view assignments:
view x, y, z;
x:= 'select 5 c1 from dual';
y:= 'select 6 c1 from dual';
z := 'select * from x union select * from y'; 4) As conventionally understood, "updatable views" result in using views as the target of a relational assignment. But this is invalid no matter how you look at it. If the assignment is of form <view> := <relation>, you've got a type violation (views have type "valid query", not "relation value"); and if you treat it as <query result> := <relation>, you're assigning to a value rather than a variable (which is no more coherent than assignment 5 := 2 + 3;). In other words, both of these are obviously illegal: z := {{c1=7},{c1=8}};
{{c1=5},{c1=6}} := {{c1=7},{c1=8}}; Received on Sat Aug 29 2009 - 05:39:02 CEST

Original text of this message