Robert>Hmm, so in your example, you actually want replanning to be able to Robert>change the cached plan's result type?
I want backend to cache _several_ plans behind a single "statement name". I want to treat "prepare...exec...deallocate" dance as an optimization step for a simple "exec...exec...exec" sequence. I do not want to care if "previously prepared query is still valid or not". For instance, I do not want to check if search_path is still the same. Current backend implementation does not report changes to "search_path", thus clients have no solid way to detect "search_path changes". David>Maybe call the new command "PARSE name AS query". >From JDBC perspective, there is no need in "prepare vs parse" distinction: 1) Explicit "prepare...execute" are not used in typical application code 2) That means, in 99.9% cases, "prepare" would be used by the jdbc driver itself 3) Thus just a single "protocol command" is sufficient. What I am saying is there are lots of consumers that want to avoid parsing overhead: plpgsql, pgjdbc, pgjdbc-ng, postgresql-async, 8kdata/phoebe, etc, etc. All of them will have to deal with search_path vs prepare issue. If you suggest to deprecate "prepare" in favor of "parse", then all of the above clients would have to switch to that "parse". It does not look like a good solution, since lots of existing clients assume "prepare just works". If "prepare" command gets deprecated, why "parse" would be better? What would be the use of "prepare" if all the clients would have to use "parse" in order to be search_path-compatible? Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
