It seems most logical to me to break the fundamental operations into:
1.  Prepare to create the compiled query plan
2.  Describe to bind the query input/output parameters
3.  Execute to produce a result set

Or equivalent functionality.  Then, you can bind all three parts into
one operation if you want to, or you can execute the tasks separately.

The notion of a flag to tell whether to return a result set or not has a
smell of kludge to me.

On the other hand, if getting something working in a hurry is the main
purpose, then a flag might be the best way to go, and it could be more
carefully refactored later.

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org 
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Saturday, October 16, 2004 3:41 PM
> To: Greg Stark
> Cc: pgsql-hackers@postgresql.org; Abhijit Menon-Sen
> Subject: Re: [HACKERS] Nearing final release? 
> 
> 
> Greg Stark <gsstark@mit.edu> writes:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> * synchonize supported encodings and docs
> 
> > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
> 
> No ... does it look like it?
> 
> > I'm not sure whether the patch he sent is adequate, I looked at it 
> > myself and was a bit skeptical. But he said my concerns were 
> > misplaced.
> 
> [ looks... ] The patch is definitely broken as-is, because it 
> changes the application-visible behavior of existing 
> functions --- in particular
> PQsendQueryParams() followed by PQgetResult() will now return 
> a bogus additional PGresult.  I think the cleanest solution 
> is probably to add a state flag indicating whether 
> ParseComplete should generate a PGresult or not.
> 
> 			regards, tom lane
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so 
> that your
>       message can get through to the mailing list cleanly
> 

Sat, 16 Oct 2004 16:04:30 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Nearing final release? 
> It seems most logical to me to break the fundamental operations into:
> 1.  Prepare to create the compiled query plan
> 2.  Describe to bind the query input/output parameters
> 3.  Execute to produce a result set
>
> Or equivalent functionality.  Then, you can bind all three parts into
> one operation if you want to, or you can execute the tasks separately.
>
> The notion of a flag to tell whether to return a result set or not has 
> a
> smell of kludge to me.
>
> On the other hand, if getting something working in a hurry is the main
> purpose, then a flag might be the best way to go, and it could be more
> carefully refactored later.

FWIW, is libpq going to have its version bumped?  There's some interest 
in having this done from the FreeBSD camp because it make detecting 
installed verions of libpq much easier (7.4 client libs working with an 
8.0 server?).  In FreeBSD the server is split from the client programs 
and its libs.  I'm sure other packagers may wish to see this happen 
too.  *shrug*  -sc

-- 
Sean Chittenden


Sat, 16 Oct 2004 17:23:21 -0700
Sean Chittenden <sean@chittenden.org>
Re: Nearing final release? 
Sean Chittenden wrote:
> > It seems most logical to me to break the fundamental operations into:
> > 1.  Prepare to create the compiled query plan
> > 2.  Describe to bind the query input/output parameters
> > 3.  Execute to produce a result set
> >
> > Or equivalent functionality.  Then, you can bind all three parts into
> > one operation if you want to, or you can execute the tasks separately.
> >
> > The notion of a flag to tell whether to return a result set or not has 
> > a
> > smell of kludge to me.
> >
> > On the other hand, if getting something working in a hurry is the main
> > purpose, then a flag might be the best way to go, and it could be more
> > carefully refactored later.
> 
> FWIW, is libpq going to have its version bumped?  There's some interest 
> in having this done from the FreeBSD camp because it make detecting 
> installed verions of libpq much easier (7.4 client libs working with an 
> 8.0 server?).  In FreeBSD the server is split from the client programs 
> and its libs.  I'm sure other packagers may wish to see this happen 
> too.  *shrug*  -sc

We do a minor libpq version bump for every major PostgreSQL release.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 16 Oct 2004 20:31:19 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Nearing final release?