Tom Lane <[EMAIL PROTECTED]> writes:

> 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?

Er, oops. I quoted the wrong line. The line I meant to quote was:

> > > * allow libpq to check parameterized data types

Which is slightly more plausible.

> > 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.

[That sounds exactly like what my concerns were.]

Adding a flag is going to be enough for synchronous queries. But it seems like
it has no chance of working for asynchronous queries. It would have to keep
track of what all the pending requests are and the expected results.

I think DBD::Pg would be pretty happy to have even synchronous queries
working. Afaik that's all it uses currently.

-- 
greg


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to