Re: Nearing final release?

From: "Dann Corbit" <DCorbit(at)connx(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Stark" <gsstark(at)mit(dot)edu>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Abhijit Menon-Sen" <ams(at)oryx(dot)com>
Subject: Re: Nearing final release?
Date: 2004-10-16 23:04:30
Message-ID: D425483C2C5C9F49B5B7A41F8944154705557F@postal.corporate.connx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Sent: Saturday, October 16, 2004 3:41 PM
> To: Greg Stark
> Cc: pgsql-hackers(at)postgresql(dot)org; Abhijit Menon-Sen
> Subject: Re: [HACKERS] Nearing final release?
>
>
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)org so
> that your
> message can get through to the mailing list cleanly
>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sean Chittenden 2004-10-17 00:23:21 Re: Nearing final release?
Previous Message Tom Lane 2004-10-16 22:41:05 Re: Nearing final release?