Re: more on delete from join
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 29 Aug 2009 03:23:11 GMT
Message-ID: <za1mm.43029$PH1.17532_at_edtnps82>
>> 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;
Date: Sat, 29 Aug 2009 03:23:11 GMT
Message-ID: <za1mm.43029$PH1.17532_at_edtnps82>
Bob Badour 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
That seems a very useful interpretation to me, maybe much better than my argument, interpretation is a big and tricky area, coalescing an accurate interpretation with a useful one is a talent Codd had. Received on Sat Aug 29 2009 - 05:23:11 CEST