Re: Set search_path + server-prepared statements = cached plan must not change result type

On Wed, Jan 27, 2016 at 10:18 PM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)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