Naz Gassiep wrote:
Let us not do the same to
SQL and implement SKYLINE on our own, only to have other DBMS vendors
implement it in different ways and then finally when the SQL standard
includes it they try to make some kind of average approximation of the
implementations resulting in *none* of the DBs being compliant. Then
we'll be between the rock of breaking backwards compatibility and the
hard place of unwarranted standards non-compliance.
While Josh did point out that being in the leading group as far as
implementing new functionality goes, I feel that it has to be weighed
against the need to not strike out too aggressively, potentially
isolating ourselves with excessive non-standard syntax or behavior.
While I am convinced there is a strong use case for this functionality
and we should definitely start looking at it, I don't see why we should
be in a rush to get it into core. People have survived without it up to
now, I don't think our userbase will suffer if it is implemented 6
months after <foo commercial DB> implements it, at least, not as much as
it will suffer if we start drifting away from standards compliance.
And where did most of the SQL standard come from? A lot of it copies or
is based on either the first db to implement a feature or the one to
implement the best syntax.
And how much of the standard became standard because most of the db's
had already implemented similar features?
Some things can syntactically be expressed more than one way, while
others are limited in ways to coherently express what you want to achieve.
If we consider this thoroughly and compile a suitable syntax that covers
all bases it could be used as the basis of the standard definition or be
close to what ends up in the standard.
--
Shane Ambler
[EMAIL PROTECTED]
Get Sheeky @ http://Sheeky.Biz
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
