Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 03 Mar 2006 15:03:17 -0500
From: "Lance J. Andersen" <Lance.Andersen@Sun.COM>
Subject: Re: JDBC4 Spec exegesis needed,
 was: [jira] Commented: (DERBY-925) Implement new JDBC 4 metadata API
 getFunctionParameters()
In-reply-to: <44087A47.9020108@apache.org>
Sender: Lance.Andersen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4408A105.1040301@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Lu8I7/B7C0WHOiGBLHAf/g)"
References: <2124723271.1141384732886.JavaMail.jira@ajax.apache.org>
 <4408748F.50904@sun.com> <44087A47.9020108@apache.org>
User-Agent: Thunderbird 1.5 (Windows/20051201)

This is a multi-part message in MIME format.

--Boundary_(ID_Lu8I7/B7C0WHOiGBLHAf/g)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT


Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>   
>> Hi Lance,
>>
>> Is it OK for a JDBC3 implementation to return more information than the
>> spec demands? In particular, consider the various result sets returned
>> by DatabaseMetaData calls. Is it OK for these result sets to contain
>> additional, trailing columns, above and beyond the columns required by
>> the JDBC3 spec? To be even more pedantic, can JDBC3 implementations
>> return the fatter JDBC4 result sets?
>>     
>
> JDBC tutorial & reference, version 2.0, sdection 15.2.2, page 369 says:
>
> "A DBMS may define additional columns for a ResultSet object that is
> returned by a DatabaseMetaData method".
>
> Not officially part of the spec, but I've always assumed the tutorial
> books are a good guideline of the spec, given the authors.
>   
While it is a good guideline, it in fact has differed at times resulting 
in driver implementation differences.

The methods in DatabaseMetaData which allow additional columns is 
documented in the javadocs.    However, it would not have been wise as a 
programmer to use anything but the column name when accessing 
non-standard columns.

-lance
> Dan.
>
>
>   

--Boundary_(ID_Lu8I7/B7C0WHOiGBLHAf/g)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Daniel John Debrunner wrote:
<blockquote cite="mid44087A47.9020108@apache.org" type="cite">
  <pre wrap="">Rick Hillegas wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Lance,

Is it OK for a JDBC3 implementation to return more information than the
spec demands? In particular, consider the various result sets returned
by DatabaseMetaData calls. Is it OK for these result sets to contain
additional, trailing columns, above and beyond the columns required by
the JDBC3 spec? To be even more pedantic, can JDBC3 implementations
return the fatter JDBC4 result sets?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
JDBC tutorial &amp; reference, version 2.0, sdection 15.2.2, page 369 says:

"A DBMS may define additional columns for a ResultSet object that is
returned by a DatabaseMetaData method".

Not officially part of the spec, but I've always assumed the tutorial
books are a good guideline of the spec, given the authors.
  </pre>
</blockquote>
While it is a good guideline, it in fact has differed at times
resulting in driver implementation differences.<br>
<br>
The methods in DatabaseMetaData which allow additional columns is
documented in the javadocs.&nbsp;&nbsp;&nbsp; However, it would not have been wise as
a programmer to use anything but the column name when accessing
non-standard columns.<br>
<br>
-lance<br>
<blockquote cite="mid44087A47.9020108@apache.org" type="cite">
  <pre wrap="">
Dan.


  </pre>
</blockquote>
</body>
</html>

--Boundary_(ID_Lu8I7/B7C0WHOiGBLHAf/g)--