From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Couple of issues with prepared FETCH commands |
Date: | 2017-01-10 22:38:20 |
Message-ID: | 87ziiywob2.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(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)
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2017-01-10 23:01:38 | Re: sequence data type |
Previous Message | Daniel Verite | 2017-01-10 22:33:17 | Re: pg_dump / copy bugs with "big lines" ? |