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.g.johnston@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