Re: Conjunction junction
Date: Mon, 01 Nov 2004 21:40:59 GMT
Message-ID: <L3yhd.4710$pY6.4648_at_trnddc04>
"Tony Andrews" <andrewst_at_onetel.com> wrote in message
news:1099340390.751573.125250_at_c13g2000cwb.googlegroups.com...
> Alan wrote:
>> "Tony Andrews" <andrewst_at_onetel.com> wrote in message >> news:1099323627.582136.287610_at_c13g2000cwb.googlegroups.com... >> > Alan wrote: >> > > The OR _should_ work like an XOR: >> > > >> > > SELECT stock_location >> > > FROM pennants >> > > WHERE color = 'red' XOR color = 'green' XOR color = 'yellow' >> > > >> > > This would return one row, namely, the first one it finds of any
> of
>> > these >> > > colors. >> > >> > No it would not, it would still return all of them, because no row
> has
>> > color='red' AND (color='green' or color='yellow') or any of the
> other
>> > combinations. To demonstrate XOR you need at least 2 attributes: >> > >> > SELECT stock_location >> > FROM pennants >> > WHERE color = 'red' XOR size = 3 XOR shape = 'square'; >> > >> > This would return pennants that are red but NOT size 3 or square,
> and
>> > pennants that are size 3 but NOT red or square, or square but NOT
> red
>> > or size 3. >> > >> > But you are right that XOR should be part of SQL. >> > >>
I have to wonder what the precedence would be of XOR in relation to NOT, AND, and OR. I imagine that it would likely be implementation specific until at least it was standardized as part of SQL. But even then, such things are often implementation specific.
>> >> What you described is two operators, OR <>, and of course we have
> that.
>
> Yes, and it is known in logic as the "exclusive OR", with a standard
> abbreviation of XOR.
Which evaluates to (p v q) ^ ~(p ^ q) using boolean primitives.
> >> The XOR I am after would behave the way I described, which is exactly >> sematically opposite of the AND operator we have. A use for this came
> up
>> recently in another NG, and it is what got me thinking about it. The
> OP
>> wanted to query a UNION of two databases, A and B, but wanted to stop
> as
>> soon as the results were found in A or found in B, thereby avoiding
> the
>> UNION. XOR would would be useful in the context of unions, but it's semantics would behave differently than what you describe (which is low level order of evaluation). An XOR in a UNION statement will have to interrogate both relations completely because it has to determine whether both subsets have corresponding tuples in which both return a result of TRUE for the condition specified. In cases meeting those conditions, such as where color is red in tuples for both A and B relations, it should not, by definition, return that subset of tuples. Thus, the distributed union query has no choice but to completely interrogate the tuples of both relations. A short-circuit precedence seems logically impossible. This requirement might be ameliorated in terms of performance by using semi-joins and the like in a distributed environment, however.
Of course this can be done procedureally, but the XOR I
> described
>> would have allowed it in straight SQL. Maybe call it an IOR
> (Immediate OR)
>> if XOR is confusing. >> >> SELECT * >> FROM A, B >> WHERE a.pk = b.pk >> AND a.color = 'red' XOR b.color = 'red' >> >> IOW, if you find it in A, don't look in B, and vice-versa. >
What about cases where one remote relation A had a tuple stating the color was red; in the other, the color in B is blue. Would this XOR over UNION be beneficial in such cases? Sounds like a recipe for distaster if one is not careful.
> Yes, you would need to use a different name because that is not what
> XOR means. What you are looking for is a quota ("TOP 1" in some SQL
> flavours), not a logical operator at all.
>
I'm not sure I agree. XOR could be a valid and useful logical operator in
conjunction with UNION. Even though the attribute in both relation
"fragments" have the same name, and we
presume to they have the same semantics, the fact that they are qualified in
two different relations makes the attributes distinguishable, assuming of
course that they are of the same type.
With specialization schemes, such as EMPLOYEES (empid, ....),
ENGINEERS(empid,...., FK EMPLOYEES(empid)), MANAGERS(empid,.....,FK
EMPLOYEES(empid)), having shortcuts or syntactic sugar to ask the question,
"give me employees who are either an Engineer or Manager, but not both or
neither, might
provide some benefit to the user, but probably not much since we can use
boolean primitives easily to get the same result.
Regards,
Dan Received on Mon Nov 01 2004 - 22:40:59 CET