Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4373FF7C.2040502@Sourcery.Org>
Date: Thu, 10 Nov 2005 18:18:36 -0800
From: Satheesh Bandaram <satheesh@Sourcery.Org>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: New features for next release .... (Was: Grant and Revoke ...
 DERBY-464...)
References: <435FCD22.3050607@Sourcery.Org>
 <7921d3e40510261152j5d8c9de8md9b3092cb89d8268@mail.gmail.com>
 <435FEE85.4040801@Sourcery.Org>
 <7921d3e40510261551m6e6a6accxcf300af1fba23352@mail.gmail.com>
 <4360146A.9000707@debrunners.com> <4360745F.8010306@Sourcery.Org>
 <17248.40844.445037.524756@gargle.gargle.HOWL>
 <43710C04.4000705@Sourcery.Org> <43711EBE.5020200@sun.com>
 <437125C8.7040502@sbcglobal.net> <437135B6.7060605@sun.com>
 <43713EA2.6090906@sbcglobal.net> <437211E0.5030208@sun.com>
 <43737897.2020604@sbcglobal.net> <4373A294.5070307@sun.com>
In-Reply-To: <4373A294.5070307@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Rick,

Rick Hillegas wrote:

>
> We will probably have to collaborate here. If you select an XML
> column, the ResultSetMetaData needs to say that the column is of type
> java.sql.SQLXML. This, at least, was the consensus of the community
> which prevented me from re-enabling the BOOLEAN datatype a couple
> months ago: Kathey and David pointed out that it was not OK for
> ResultSetMetaData to report a boolean column's type as SMALLINT.
> Similarly, it's not going to be OK for ResultSetMetaData to report the
> type of an XML column as java.sql.LONGVARCHAR.

It doesn't seem right to expose a JDBC 4.0 type to a JDBC 3.0 client.
What good would that do, since JDBC 3.0 clients are probably written to
expect JDBC 3.0 functionality only? I wonder if we might even break GUIs
and other generic tools that expect 3.0 types only. Since we may be
close to enabling full JDBC 4.0 in the near term, why not expose only
JDBC 3.0 types to 3.0 clients? That is to expose XML type as a CLOB
under JDBC 3.0 and as SQLXML for a JDBC 4.0 client. This would expose a
new type to Derby server, XML, to JDBC by mapping it to it's closest
match. Remember the TINYINT discussion and Dan's point?

I don't remember what was discussed about this during the BOOLEAN
discussion... but if JDBC already supports a boolean type, that would
seem correct to map it to, rather than say SMALLINT.

Satheesh