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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
