From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Nearing final release? |
Date: | 2004-10-17 00:31:19 |
Message-ID: | 200410170031.i9H0VJa09140@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-10-17 05:10:14 | Re: Nearing final release? |
Previous Message | Bruce Momjian | 2004-10-17 00:29:45 | Re: Nearing final release? |