db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ян Программист <webautoma...@gmail.com>
Subject Re: Google Summer of Code
Date Thu, 18 Mar 2010 11:08:52 GMT
That is clearly understood. And how it is connected to the things against
data types? You wrote that that it make sense to figure out data types
compatibility. I thought the main focus in SQL variations that force
different strategies of data conversion when executing statements. Explain.
John

2010/3/17 Bryan Pendleton <bryanwpendleton@gmail.com>

> ?? ??????????? 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.
>
> thanks,
>
> bryan
>
>

Mime
View raw message