Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: domain of webautomator@gmail.com
 designates 209.85.220.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=iF0NfrHeIXSD9LPlGugvE9Ux+uHtEeV+45jX8I1e1Oza7Qy56+Ge0zXVESkwD/NvUW
         nnrYO8pJotY00Pb4LHenl14krCYF0/4Soql0O5AmQXy8ang8hkYKoPcc4bbOYRGmVjPs
         WCz5nWqZXwJwoBZLFoiqbv/mbxNuevJpfXCz8=
MIME-Version: 1.0
In-Reply-To: <4BA10732.5040607@gmail.com>
References: <855911.22501.qm@web29112.mail.ird.yahoo.com>
	 <4B9F9E8A.5090303@gmail.com>
	 <93d36c111003160833x1d40b4bbw7d2c00275e90a75@mail.gmail.com>
	 <4B9FAA82.9090003@gmail.com>
	 <93d36c111003170457y13e98dfbic7a5d2468e7c37e4@mail.gmail.com>
	 <93d36c111003170612t62272f1bl5c5b9e0d907d2f7d@mail.gmail.com>
	 <4BA0EB92.3010501@gmail.com>
	 <93d36c111003170750k29e6d20bx8c8a1f9db907efad@mail.gmail.com>
	 <93d36c111003170803o19f710ecneea73ed8c680b3a7@mail.gmail.com>
	 <4BA10732.5040607@gmail.com>
Date: Thu, 18 Mar 2010 13:08:52 +0200
Message-ID: <93d36c111003180408k486dd841sde6f3984a86cdd22@mail.gmail.com>
Subject: Re: Google Summer of Code
From: =?KOI8-R?B?8c4g8NLPx9LBzc3J09Q=?= <webautomator@gmail.com>
To: derby-dev@db.apache.org
Content-Type: multipart/alternative; boundary=001485f87cfc8bcb7e048211415a

--001485f87cfc8bcb7e048211415a
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--001485f87cfc8bcb7e048211415a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

That is clearly understood. And how it is connected to the things against d=
ata types? You wrote that that it make sense to figure out data types compa=
tibility. I thought the main focus in SQL variations that force different s=
trategies of data conversion when executing statements. Explain. John <br>
<br><div class=3D"gmail_quote">2010/3/17 Bryan Pendleton <span dir=3D"ltr">=
&lt;<a href=3D"mailto:bryanwpendleton@gmail.com">bryanwpendleton@gmail.com<=
/a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1=
px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"=
>
<div class=3D"im">?? ??????????? wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
No, not understood. You are focusing on JDBC compatibility from the databas=
e side? Or you looking for compatibility of types, not provided to JDBC? Th=
ere are convertions to generic* types due to JDBC connectivity issues... SQ=
L code would run in most cases, but data would not always be consistent. Co=
nsistency is a MUST, as I understood (?). Explain more detailed. John<br>

</blockquote>
<br></div>
Hi John,<br>
<br>
It is true that SQL code runs in most cases, but there are many small<br>
variations between the precise features of SQL that are supported by<br>
the various database implementations.<br>
<br>
Consider, for example, the ORDER BY clause.<br>
<br>
Most database systems allow ORDER BY to be present in simple SELECT stateme=
nts:<br>
<br>
 =A0select id, firstname, lastname from employee order by lastname<br>
<br>
This has been part of the SQL standard for 20 years and is widely supported=
.<br>
<br>
However, there are lots of variations on this SQL statement. For example,<b=
r>
is it supported to use ORDER BY on a column which is not present in the SEL=
ECT<br>
list, as in:<br>
<br>
 =A0select id from employee order by lastname<br>
<br>
Or, is it supported to use ORDER BY on an expression, as in:<br>
<br>
 =A0select lastname from employee order by lower(lastname)<br>
<br>
Or, is it supported to use ORDER BY in a sub-query, as in:<br>
<br>
 =A0select * from (select lastname from employee order by lastname) t<br>
<br>
Over the years, we have tracked down many such variations of SQL statements=
, and<br>
explored the issues of how Derby&#39;s support for SQL compares to the supp=
ort<br>
provided by databases such as MySQL or Postgres (or others).<br>
<br>
These are the sorts of compatibility issues I was particularly referring to=
.<br>
<br>
thanks,<br><font color=3D"#888888">
<br>
bryan<br>
<br>
</font></blockquote></div><br>

--001485f87cfc8bcb7e048211415a--