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

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

Reply via email to