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
>