Thread

1. Re: Nearing final release?

   Dann Corbit <dcorbit@connx.com> — 2004-10-16T23:04:30Z

   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
   > 
   
   

2. Re: Nearing final release?

   Sean Chittenden <sean@chittenden.org> — 2004-10-17T00:23:21Z

   > 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
   
   
   

3. Re: Nearing final release?

   Bruce Momjian <pgman@candle.pha.pa.us> — 2004-10-17T00:31:19Z

   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