Re: [HACKERS] PREPARE - Mailing list pgsql-hackers

From Peter T Mount
Subject Re: [HACKERS] PREPARE
Date
Msg-id Pine.LNX.3.96.981117183349.3444G-100000@maidast.retep.org.uk
Whole thread Raw
In response to Re: [HACKERS] PREPARE  (Michael Meskes <meskes@usa.net>)
Responses Re: [HACKERS] PREPARE  (Michael Meskes <meskes@usa.net>)
List pgsql-hackers
On Tue, 17 Nov 1998, Michael Meskes wrote:

> On Mon, Nov 16, 1998 at 02:19:32PM -0600, Taral wrote:
> > separate stages. Are we also planning to support PREPARE? If so, we should
> > co-ordinate the effort, since the full COSQS support will require pulling
> > apart pg_parse_and_plan().
> 
> Hopefully. I'm still holding back PREPARE for ecpg until I can think of a
> good solution. The best of course would be in the backend. Hmm, how do ODBC
> and JDBC solve this?

Background:

JDBC has a class called PrepareStatement. It's created by the
prepareStatement() method in the Connection class. The statement passed to
it has each required parameter represented by a ?

insert into mytable (field1,field2,field3) values (?,?,?);

Now the current postgresql jdbc implementation stores this string, and has
a Vector (Java for a dynamic array) that has each value stored in it as
the client application sets them. When the client calls the
executeUpdate() or executeQuery() methods, we just replace the ?'s with
the values in sequence, and pass the query to the backend as normal.

It's a real botch, but it works.

--       Peter T Mount peter@retep.org.uk     Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf



pgsql-hackers by date:

Previous
From: Stephen Kogge
Date:
Subject: building 6.4 on sunos 4.1.4
Next
From: dg@informix.com (David Gould)
Date:
Subject: Re: [HACKERS] More PostgreSQL+CORBA