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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Saturday, October 16, 2004 3:41 PM > To: Greg Stark > Cc: [EMAIL PROTECTED]; Abhijit Menon-Sen > Subject: Re: [HACKERS] Nearing final release? > > > Greg Stark <[EMAIL PROTECTED]> writes: > > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so > that your > message can get through to the mailing list cleanly > ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
