On Wed, Jan 11, 2017 at 11:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth
>> wrote:
>>> But the problem that actually came up is this: if you do the PQprepare
>>> before the
Robert Haas writes:
> On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth
> wrote:
>> But the problem that actually came up is this: if you do the PQprepare
>> before the named cursor has actually been opened, then everything works
>> _up until_ the
> "Robert" == Robert Haas writes:
>> But the problem that actually came up is this: if you do the
>> PQprepare before the named cursor has actually been opened, then
>> everything works _up until_ the first event, such as a change to
>> search_path, that forces a
On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth
wrote:
> But the problem that actually came up is this: if you do the PQprepare
> before the named cursor has actually been opened, then everything works
> _up until_ the first event, such as a change to search_path, that
(This came up on IRC, but I'm not sure to what extent it should be
considered a "bug")
If you do PQprepare(conn, "myfetch", "FETCH ALL FROM mycursor", ...);
then the results are unpredictable in two ways:
Firstly, nothing causes the plancache entry to be revalidated just
because "mycursor" got