>>>>> "Robert" == Robert Haas <robertmh...@gmail.com> 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 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. Robert> To me, that sounds like a bug. So what's the appropriate fix? My suggestion would be to suppress the result type check entirely for utility statements; EXPLAIN and SHOW always return the same thing anyway, and both FETCH and EXECUTE are subject to the issue described. This would mean conceding that the result descriptor of a prepared FETCH or EXECUTE might change (i.e. a Describe of the statement might not be useful, though a Describe of an opened portal would be ok). I think this would result in the most obviously correct behavior from the client point of view. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
