Re: [HACKERS] Couple of issues with prepared FETCH commands

2017-03-09 Thread Robert Haas
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

Re: [HACKERS] Couple of issues with prepared FETCH commands

2017-01-11 Thread Tom Lane
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

Re: [HACKERS] Couple of issues with prepared FETCH commands

2017-01-11 Thread Andrew Gierth
> "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

Re: [HACKERS] Couple of issues with prepared FETCH commands

2017-01-11 Thread Robert Haas
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

[HACKERS] Couple of issues with prepared FETCH commands

2017-01-10 Thread Andrew Gierth
(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