Re: Nearing final release? - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Nearing final release?
Date
Msg-id 87fz4e2amh.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Nearing final release?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Nearing final release?
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

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

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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Nearing final release?
Next
From: Neil Conway
Date:
Subject: additional GCC warnings