db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Overly conservative on reserved words?
Date Tue, 01 Mar 2005 18:12:35 GMT
I couldn't agree more. Being a non-commercial database, Apache Derby
shouldn't be laying "minnow traps". Derby should provide easy migration
path to leading commercial databases. Take for example, the recently
added UNION/INTERSECT DISTINCT clause. This doesn't add any new
functionality to Derby, since the default is the DISTINCT. Having this
syntax will create problems for migrating to DB2, Oracle, Informix. (I
only briefly searched for support in Oracle 10i database. They don't
seem to have it.) I haven't looked at Sybase and others.  Why have this
syntax when it doesn't add any value but creates hurdles to applications?

I am tempted to call for a vote to rollback the change to add DISTINCT
clause to set operators, but will wait for community input before doing
so. I do hope Derby will remain "non-proprietary" in a common sense way.
API compatibility in SQL and JDBC is a great asset to have...

Satheesh

Jack Klebanoff wrote:

> Jeremy Boynes wrote:
>
>> Daniel John Debrunner wrote:
>>
>>> Jeremy Boynes wrote:
>>>
>>>
>>>> Reserving additional words from the second group poses a bigger
>>>> issue as
>>>> users' may have databases out there already using these words as
>>>> identifiers. The smoothest path is probably to give people an
>>>> indication
>>>> of which words will need to be reserved at some point and hence should
>>>> be avoided; it is better for us to do this earlier than later.
>>>
>>>
>>>
>>>
>>> Actually having even keywords defined as reserved by the SQL Standard
>>> reserved in Derby has caused problems. I recently changed LOCAL not to
>>> be a reserved word as other databases do not enforce it. We probably
>>> need some set rules, but reserving because the SQL standard says so it
>>> not the approach taken by other products.
>>>
>>
>> 'The nice thing about standards is there are so many to choose from' :-)
>> Especially true with 4 versions of ISO SQL and N vendor-specific
>> dialects. One of the issues users face is that the spec evolves and
>> products implement newer versions, words that were not reserved
>> before now need to be.
>>
>> Ideally we would not need to reserve anything, giving users complete
>> freedom on how they name their things; however, that would make the
>> parser, lets say, challenging. Short of this ideal, I think we should
>> compormise and only reserve words needed to resolve ambiguity in the
>> parser; that lets users decide how much portability they need. To
>> help them do that I think it's useful for us to indicate direction
>> and what is likely to be reserved (SAVEPOINT) vs. what isn't
>> (PERCENTILE_DISC).
>>
>> Is it worth raising a warning on DDL operations that define objects
>> that conflict with SQL's reservation list?
>>
>> -- 
>> Jeremy
>>
> I am uneasy about offering extensions to the SQL standard. Every
> extension is a "minnow trap" making it difficult for developers to
> port applications from Derby to other relational databases. Many,
> perhaps most, developers are not that vigilant about all the fine
> points of standards and portability. Often they do not consciously
> decide how much portability they need, but use whatever gets their
> application going and find out later whether it is portable.
>
> We have to decide what Derby's goals are. Currently part of our
> charter says "developers can later migrate to other databases if they
> so choose". As long as this remains an important part of Derby's
> charter we should try to keep Derby a subset of the latest SQL
> standard, and we should avoid features that are incompatible with
> leading enterprise relational database management systems.
>
> (A real minnow trap is a device used to catch minnows, small bait
> fish. The trap is a cylindrical cage with funnel like openings at
> either end. You put some food in the cage. Minnows find it easy to
> swim in but hard to swim out).
>
> Jack
>
>
>


Mime
View raw message