On Thu, 12 Feb 1998, The Hermit Hacker wrote:
> On Thu, 12 Feb 1998, Peter T Mount wrote:
>
> > Getting most of the rest of DatabaseMetaData is my main priority after 6.3
> > is released. However, there are some methods that cannot yet be
> > implemented because postgresql itself isn't yet up to it.
>
> Like? Maybe you should coordinate with Bruce, as far as the TODO
> list is concerned, and have a JDBC section, that has notes attached to
> those that require something from the PostgreSQL section? Or annotate te
> PostgreSQL section pieces with "needed for JDBC driver"?
There's quite a few.
Below is a list of what I think we still have to work on.
Most of the text here are notes from the source. Most of these were put in
by either myself, or Adrian.
DatabaseMetaData:
We have some methods that should return the available functions.
They are:
getNumericFunctions, getStringFunctions,
getSystemFunctions, getTimeDateFunctions
Ok, our functions are in pg_proc, but how to differenciate them?
supportsTableCorrelationNames()
Are table correlation names supported? A JDBC-Compliant driver
always returns true. We return false here. Do we support this?
supportsCoreSQLGrammar()
Does this driver support the Core ODBC SQL grammar. We need SQL-92
conformance for this. We return false here.
supportsExtendedSQLGrammar()
Does this driver support the Extended (Level 2) ODBC SQL grammar.
We don't conform to the Core (Level 1), so we can't conform to the
Extended SQL Grammar.
supportsANSI92EntryLevelSQL()
Does this driver support the ANSI-92 entry level SQL grammar?
All JDBC Compliant drivers must return true. I think we have to
support outer joins for this to be true.
PreparedStatement:
This e A SQL statement is pre-compiled and stored in a
PreparedStatement object. This object can then be used to
efficiently execute this statement multiple times.
What we actually do in the driver, is store the statement, then on
each execute, builds a query, then sends it to the backend.
I think some one recently (last week) said they were doing
something with the parser to store pre-parsed statements?
CallableStatement: This we don't implement at all! As this uses stored
procedures, do we support them, and if so, do we have some examples?
This is from the JDBC API docs:
CallableStatement is used to execute SQL stored procedures.
JDBC provides a stored procedure SQL escape that allows stored
procedures to be called in a standard way for all RDBMS's. This escape
syntax has one form that includes a result parameter and one that does
not. If used, the result parameter must be registered as an OUT
parameter. The other parameters may be used for input, output or both.
Parameters are refered to sequentially, by number. The first parameter
is 1.
{?= call <procedure-name>[<arg1>,<arg2>, ...]}
{call <procedure-name>[<arg1>,<arg2>, ...]}
IN parameter values are set using the set methods inherited from
PreparedStatement. The type of all OUT parameters must be registered
prior to executing the stored procedure; their values are retrieved
after execution via the get methods provided here.
A Callable statement may return a ResultSet or multiple ResultSets.
Multiple ResultSets are handled using operations inherited from
Statement.
For maximum portability, a call's ResultSets and update counts should
be processed prior to getting the values of output parameters.
--
Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
