On Wed, Jan 27, 2016 at 10:18 PM, David G. Johnston <david.g.johns...@gmail.com> wrote: > Prepare creates a plan and a plan has a known output structure. What you > want is an ability to give a name to a parsed but unplanned query. This is > not something that prepare should do as it is not a natural extension of its > present responsibility.
The distinction you're talking about here actually does exist at the Protocol level. You can send a Parse message to create a prepared statement (which is parsed but unplanned), a Bind message to create a portal (which is planned), and then you can send an Execute message to execute a previously-created portal. However, I'm not really sure this helps. It seems like what Vladimir wants is basically automatic plan caching. He wants the server to re-parse-analyze and re-plan the statement any time that would produce a different outcome, but ideally also consider holding onto the old plan in case the search_path or whatever is switched back. I gather that the reason he wants to use prepared statements at all is just to minimize parse-plan overhead. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
