Re: [QUESTIONS] full JDBC driver ? - Mailing list pgsql-hackers

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