db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Date Fri, 10 Jul 2009 17:20:55 GMT

Dag H. Wanvik wrote:
> I think the mitigating circumstance here is that Rick says that this
> is an *omission* on part of the SQL standards committee. Naturally,
> they might change the syntax entirely for 2011, or choose *not* to
> allow this anyway, but that hardly seems likely. The OFFSET, FETCH
> FIRST/NEXT syntax is now fixed in three places (at least: the
> standard, PostgresQL and DB2). To me it seems a very low risk to take;
> we *are* supporting the standard syntax: In addition we are fixing the
> committee's omission in expectation that this will be included.
> 
> I guess this all boils down how strictly we interpret our charter of
> following the standard. I worry our users will see our barring this as
> being overly careful at the cost of usability. 
> 
> Anyway, I'm out for 2 weeks, so this won't make 10.5.2 in any case ;)
> 
> Dag
> 

After reading the subsequent info in this thread I think allowing this 
specific
non-standard extension is ok.  In general I still do believe that Derby 
should
continue it's charter as a standard's based DB, and that just because other
db's have implemented non-standard behavior that is not enough to implement
them in Derby.

The main points that convinced me are:
1) Work has been done to interact with he standard committee and it seems
    this is in keeping with the intent of the standard, and very likely to
    appear in a standard in the future.
2) The oversight of the standard has made the feature unusable in some
    applications, and the use of ? parameters in this case is the normal way
    Derby applications get performance.
3) This is an extension, not a breaking of the existing standard.

It would be good to see clear documentation of this feature as a 
non-standard
implementation, maybe with some note that if a standard comes in this 
area we
may change the behavior to match it.

Mime
View raw message