Re: PostgreSQL - 'SKYLINE OF' clause added! - Mailing list pgsql-hackers

Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> I think if the code is good enough, and we can avoid horrible non-standard 
>> syntax extensions, they should go in.   We have to defend our title as "most 
>> advanced database" and having stuff like Skyline first (before DB2 or MS) 
>> goes a long way for that.
> 
> Well, whether it's horrible or not is in the eye of the beholder, but
> this is certainly a non-standard syntax extension.

Being non-standard should not be the only reason to reject a worthwhile 
feature. Do you really believe that the SQL standard covers every 
feature that a RDBMS could ever want to implement? Do you think that the 
current non-standard features of PostgreSQL should be removed?

> My questions about whether to adopt it have more to do with
> cost/benefit.  I haven't seen the patch, but it sounds like it will be
> large and messy; and it's for a feature that nobody ever heard of before,
> let alone one that the community has developed a consensus it wants.
> I'm not interested in adopting stuff just "because DB2 hasn't got it".

Partially agree but I do think it is worth looking at to see if some or 
all of the feature is worth implementing. The fact that several 
different groups have been mentioned to be working on this feature would 
indicate that it is worth considering. Maybe one of the other groups 
will have implemented it better than the first off the rank. Maybe our 
core developers can work out a better way to implement these features.

A few people on this list have said they are interested in this.

> It's also worth noting that what we've got here is a large patch
> developed, by students, completely outside our normal development
> process; so the odds that it's going to be anywhere near acceptable are
> low.  I think the last time we applied a patch that met that description
> was the INTERSECT/EXCEPT patch in 1999 ... maybe you don't remember
> what a fiasco that was, but I do.

True but the quals he has listed on his web pages look impressive and 
probably give him a little reason to have his work considered/looked at. 
He may just end up being a main PostgreSQL developer in the future.

> Sorry to be a thrower of cold water, but I just don't see that this
> comes anywhere near being something we should be eager to accept.

True we shouldn't just say "sounds good let's put it in" but with some 
indication that this feature is along the lines of what users want, 
would indicate that we should be asking -

Do we want this or a similar feature?
Is the theory behind this feature solid?
Can the same end results be gained with other existing methods?
Is the implementation offered worth considering?
Has it been developed to meet the PostgreSQL developer guidelines?
Is it reasonable to work on it to reach a level of quality/performance 
that we will be happy to include?
Can we implement this feature better ourselves?
Do we want to start this feature from scratch ourselves?



-- 

Shane Ambler
pgSQL@Sheeky.Biz

Get Sheeky @ http://Sheeky.Biz