Re: [HACKERS] Couple of issues with prepared FETCH commands
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Couple of issues with prepared FETCH commands |
Дата | |
Msg-id | 7472.1484195313@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Couple of issues with prepared FETCH commands (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Couple of issues with prepared FETCH commands
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth > <andrew@tao11.riddles.org.uk> 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 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. > To me, that sounds like a bug. Yeah --- specifically, I wonder why we allow the reference to an unrecognized cursor name to succeed. Or were you defining the bug differently? regards, tom lane
В списке pgsql-hackers по дате отправления: