Horton

Thread

  1. Re: [QUESTIONS] full JDBC driver ?

    Peter T Mount <postgresdev@maidast.demon.co.uk> — 1998-02-13T22:08:37Z

    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

  2. Re: [HACKERS] Re: [QUESTIONS] full JDBC driver ?

    Phil Thompson <phil@river-bank.demon.co.uk> — 1998-02-14T00:05:24Z

    Peter T Mount wrote:
> 
> 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?

Isn't the "right" way to do this to implement the standard
INFORMATION_SCHEMA, then all frontends have a decent model to work to?

Phil

  3. Re: [HACKERS] Re: [QUESTIONS] full JDBC driver ?

    Peter T Mount <psqlhack@maidast.demon.co.uk> — 1998-02-14T11:03:54Z

    On Sat, 14 Feb 1998, Phil Thompson wrote:

> Peter T Mount wrote:
> > 
> > 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?
> 
> Isn't the "right" way to do this to implement the standard
> INFORMATION_SCHEMA, then all frontends have a decent model to work to?
> 
> Phil

Possibly. Where possible, we have either default or assumed values where
there is no (visible) way of getting these values.

I did miss one bit out of the last post: There is a problem with
getColumnPrivileges(), in that it will never work while pg_user is not
readable by public.

I know that someone (vadim?) was trying to work out where to store the
passwords (other than in pg_user).

Anyhow, now I've finished the courses my employer keeps sending me on, I
can now spend more time on this ;-)

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