db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bryanwpendle...@gmail.com>
Subject Re: Google Summer of Code
Date Wed, 17 Mar 2010 16:45:38 GMT
?? ??????????? wrote:
> No, not understood. You are focusing on JDBC compatibility from the 
> database side? Or you looking for compatibility of types, not provided 
> to JDBC? There are convertions to generic* types due to JDBC 
> connectivity issues... SQL code would run in most cases, but data would 
> not always be consistent. Consistency is a MUST, as I understood (?). 
> Explain more detailed. John

Hi John,

It is true that SQL code runs in most cases, but there are many small
variations between the precise features of SQL that are supported by
the various database implementations.

Consider, for example, the ORDER BY clause.

Most database systems allow ORDER BY to be present in simple SELECT statements:

   select id, firstname, lastname from employee order by lastname

This has been part of the SQL standard for 20 years and is widely supported.

However, there are lots of variations on this SQL statement. For example,
is it supported to use ORDER BY on a column which is not present in the SELECT
list, as in:

   select id from employee order by lastname

Or, is it supported to use ORDER BY on an expression, as in:

   select lastname from employee order by lower(lastname)

Or, is it supported to use ORDER BY in a sub-query, as in:

   select * from (select lastname from employee order by lastname) t

Over the years, we have tracked down many such variations of SQL statements, and
explored the issues of how Derby's support for SQL compares to the support
provided by databases such as MySQL or Postgres (or others).

These are the sorts of compatibility issues I was particularly referring to.



View raw message