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
