> Greg Stark <[EMAIL PROTECTED]> writes: > > Removing <,<=,>,>= would be trivial. > > ... and not backwards-compatible. If we did that then cases involving > unlabeled row expressions would no longer work as they did in prior > releases. For example > > select (1,2,3) < (4,5,6); > > is accepted by all releases back to 7.0, and probably much further (but > 7.0 is the oldest I have handy to test). The only reason the code in > parse_expr.c appears new is that the functionality used to be in gram.y. > > I'd like to see this fixed to comply with the spec, but given the lack > of complaints about the existing behavior over so many years, ripping > it out meanwhile doesn't seem appropriate.
Just to clarify: I think Greg is arguing to bring pg to SQL 92 spec and not remove anything. ISTM the SQL standard was designed with exactly my problem in mind: how to get the next key in a table. IMHO, relying on select (1,2,3) < (4,5,6); to give a result which is neither standard nor documented seems to be bad style. The current methodology could cause pg to give incorrect results in TPC benchmarks...not good. Also, it's trivial to rewrite that comparison with the old behavior using 'and'. OTOH, it is not trivial to rewrite the comparison to do it the correct way...it's kind of an SQL 'trick question'. Most likely, a very small minority of pg users are even away of the above syntax anyways. To be fair, I'm a big fan of deprecating features for at least one release for compatibility reasons. It's no big deal to me, because I'm already writing the queries out the long way anyways. My interests are in the optimizer. If there is a way to enhance it so that it multi-column comparisons in a logical way, that would be great. Is this theoretically possible (probable)? Merlin ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])