Re: more on delete from join

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 29 Aug 2009 17:41:13 -0300
Message-ID: <4a999271$0$23747$9a566e8b_at_news.aliant.net>


Kevin Kirkpatrick wrote:

> On Aug 29, 10:32 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
> 

>>On Aug 29, 9:45 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>
>>
>>
>>
>>
>>>Kevin Kirkpatrick wrote:
>>>
>>>>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...)
>>
>>>I agree. The former is klunky and inelegant while the latter is elegant
>>>and clear.
>>
>>What should these clear and elegant programs print?
>>
>>int x, y;
>>y:=3;
>>x:=y;
>>print (x);
>>y:=4;
>>print (x);
>>--------
>>int x, y;
>>y:=3;
>>x+y:=5;
>>print(x);
>>y:=4;
>>print(x);
> 
> 
> On Aug 29, 10:32 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
> 

>>On Aug 29, 9:45 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>
>>
>>
>>
>>
>>>Kevin Kirkpatrick wrote:
>>>
>>>>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...)
>>
>>>I agree. The former is klunky and inelegant while the latter is elegant
>>>and clear.
>>
>>What should these clear and elegant programs print?
>>
>>int x, y;
>>y:=3;
>>x:=y;
>>print (x);
>>y:=4;
>>print (x);
>>--------
>>int x, y;
>>y:=3;
>>x+y:=5;
>>print(x);
>>y:=4;
>>print(x);
>
> One final example - what does this print:

How the fuck should I know what some language you just made up prints? Received on Sat Aug 29 2009 - 22:41:13 CEST

Original text of this message