[HACKERS] Couple of issues with prepared FETCH commands

(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 opened with a different query, so the result type
can change between uses.  This could be considered a "caveat user" case,
though, and I can't find anything that actually breaks.

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 revalidation; and at that point it fails with the "must not change
result type" error _even if_ the cursor always has exactly the same
result type.  This happens because the initial prepare actually stored
NULL for plansource->resultDesc, since the cursor name wasn't found,
while on the revalidate, when the cursor obviously does exist, it gets
the actual result type.

It seems a bit of a "gotcha" to have it fail in this case when the
result type isn't actually being checked in other cases.

(In the reported case, search_path was actually changing due to the
creation of a temp table, so there was a certain amount of
spooky-action-at-a-distance to figure out in order to locate the
problem.)

-- 
Andrew (irc:RhodiumToad)