I allready took my statement back, about an hour after I said this.
But yes, I agree that the left-right approach would be intuitive (same as
compound index).
In mathematics it is called lexical order, I only thought this would be hard
to implement.
Also there are a lot of operators (all negated Op's that) will want an _OR_
e.g. !=~, not only <>

So all not very easy, I'll try to think some more about it.
Andreas
> ----------
> Von: 	Bruce Momjian[SMTP:maillist@candle.pha.pa.us]
> Gesendet: 	Dienstag, 17. Februar 1998 17:15
> An: 	Zeugswetter Andreas SARZ
> Cc: 	pgsql-hackers@hub.org
> Betreff: 	Re: [HACKERS] Re: Subselects open issue Nr. NEW
> 
> > 
> > Gosh, please leave it in it is superb, great, fantastic ... 
> > If somebody defines a different behavior as standard in the future,
> > we will need to tell him that he has a gordian knot in his brains :-)
> > 
> > Andreas 
> > 
> > > I understand this. And this is how it works currently:
> > > 
> > > select * from tab where (A,B) >= ANY (select X, Y from tab2);
> > > 
> > > means: select tuples where A >= X _and_ B >= Y for some tuple from
> tab2.
> > >                                   ^^^^^
> > >          'AND' is used for all Op-s except for '<>' when 'OR' is used.
> > > 
> > > Question is "should we drop this feature (?) or leave it as is ?"
> > 
> > 
> > 
> 
> I think my recent posting answers this.  You have to comare from
> left-to-right until you find an answer.
> 
> -- 
> Bruce Momjian
> maillist@candle.pha.pa.us
> 
> 

Tue, 17 Feb 1998 17:34:19 +0100
Zeugswetter Andreas SARZ <Andreas.Zeugswetter@telecom.at>
AW: [HACKERS] Re: Subselects open issue Nr. NEW
> But yes, I agree that the left-right approach would be intuitive (same as
> compound index).
> In mathematics it is called lexical order, I only thought this would be hard
> to implement.
> Also there are a lot of operators (all negated Op's that) will want an _OR_
> e.g. !=~, not only <>

We had started discussing this back when we implemented the general SQL92
syntax for multiple left-hand arguments in expressions.

One possibility was to make the generalization that any operator with "!" or
"<>" (others too?) in the operator string would be handled as a negation, and
all others otherwise. Then, many operators would "magically" work correctly or
intuitively, while a few, perhaps, would not behave correctly. However, imho
this is preferable to not allowing _any_ of these, and perhaps we would learn
over the next few months a way to tighten it up...

                                                       - Tom


Tue, 17 Feb 1998 16:48:27 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: AW: [HACKERS] Re: Subselects open issue Nr. NEW
Thomas G. Lockhart wrote:
 
> One possibility was to make the generalization that any operator with "!" or
> "<>" (others too?) in the operator string would be handled as a negation, and
> all others otherwise. Then, many operators would "magically" work correctly or
> intuitively, while a few, perhaps, would not behave correctly. However, imho
> this is preferable to not allowing _any_ of these, and perhaps we would learn
> over the next few months a way to tighten it up...
> 
>                                                        - Tom

Since we can't tell by the 'name' of the operator what it does (it
works often, but not always) without imposing regulations on the
naming of operators...
...add a column to pg_operator to tell what kind of operator it is:

Group	Examples
-------	--------
EQ	=
NE	<>
LT	<
GT	>
LE	<=
GE	>=
OTHER	<-> <?> @-@ ## *~ !== *=~ etc...

(or give the operators other attributes which can be used to find out
 if we should use OR or AND when rewriting '(x,y) OP (z,q)' queries).

... and then just check what group of operator we are dealing with.
If it is "OTHER", then produce an ERROR or NOT IMPLEMENTED message.


This could be useful in other places too. I think I have seen something
about this some weeks or months ago, when somebody had problems finding
out how to select an appropriate operator, and just had to *assume*
that "=" was the equality operator in all cases (which might not always
be true, and will create hard-to-find bugs sooner or later, since 
most people will never think of the possibility that someone will use
something else than '=' for equality...)

/* m */

Wed, 18 Feb 1998 18:20:51 +0100
Mattias Kregert <matti@algonet.se>
Re: AW: [HACKERS] Re: Subselects open issue Nr. NEW