Re: Thinking about MINUS
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 07 Jan 2007 19:06:52 GMT
Message-ID: <gxboh.41808$cz.613913_at_ursa-nb00s0.nbnet.nb.ca>
>
> Maybe, and I would be curious to see that definition work. I believe
> the conventional stance (ie., most products' stance) is that the result
> is undefined. If I have that right, my attitude is that means an
> implementation must support exceptions to handle it. Although I don't
> object to having exceptions if they give some programming or user
> safety, for some reason I can't explain, I don't like the idea of a
> system that allows undefined conditions to be produced and then must
> support exceptions to cope with them.
>
> Apart from that, when the types are the same, even the most frequent
> conventional union/"INSERT" disturbs me a little, ie., when its
> definition is based on OR or <OR> in TTM and we have a candidate key. I
> suppose that when a system supports assignment to a variable and two
> tuples in union'ed relation operands are contradictory, maybe it is
> reasonable for NEITHER to show up in the result!
Date: Sun, 07 Jan 2007 19:06:52 GMT
Message-ID: <gxboh.41808$cz.613913_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
>> paul c wrote: >> >>> Walt wrote: >>> ... >>> >>>> Either NOR or NAND are enough to bootstrap to the rest of it, >>>> provided you >>>> make one little extension to them: >>>> >>>> NOR or NAND with only one operand is NOT. >>>> >>>> I don't know where it leads regarding database, either. Just a random >>>> thought. >>> >>> One of a couple of reasons this topic intrigues me is that certain >>> scenarios aren't closed for operations in Codd's framework, eg., the >>> case when two operands share an attribute name that has different >>> types. I realize that a whole sub-industry has been built to deal >>> with problems like this (based on various design disciplines, >>> knowingly or unknowingly, I don't know), so many people would say I'm >>> silly to wonder, but I can't help it. >> >> Wouldn't one end up with a resulting attribute defined as a union-type >> in a relation with no rows?
>
> Maybe, and I would be curious to see that definition work. I believe
> the conventional stance (ie., most products' stance) is that the result
> is undefined. If I have that right, my attitude is that means an
> implementation must support exceptions to handle it. Although I don't
> object to having exceptions if they give some programming or user
> safety, for some reason I can't explain, I don't like the idea of a
> system that allows undefined conditions to be produced and then must
> support exceptions to cope with them.
>
> Apart from that, when the types are the same, even the most frequent
> conventional union/"INSERT" disturbs me a little, ie., when its
> definition is based on OR or <OR> in TTM and we have a candidate key. I
> suppose that when a system supports assignment to a variable and two
> tuples in union'ed relation operands are contradictory, maybe it is
> reasonable for NEITHER to show up in the result!
Assignment is a whole different ball of wax, though, and context is very important. In one context, the user might want the dmbs to evaluate the join as I described above, and in another context the user might want the dbms to report an error (or at least a warning.)
Particularly, when the user tries to assign the resulting relation to a relvar, the dbms may not have a mechanism to properly respresent the union type to the user -- resulting in an error on assignment. Received on Sun Jan 07 2007 - 20:06:52 CET