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

On Monday, January 25, 2016, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
wrote:

> I want to treat 'prepare' operation as an optimization step, so it is
> functionally equivalent to sending a query text.
>
> In other words, I would like backend to track search_path and other
> parameters if necessary transparently‎, creating (caching) different
> execution plans if different plans are required.
> ‎
> Does that make sense?‎
> ‎
>

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.

Maybe call the new command "PARSE name AS query".

Subsequent prepare commands could refer to named parsed commands to
generate an execution plan in the current context. If the current context
matches a previously existing plan the command would effectively become a
no-op. Otherwise a new plan would be generated. Or, more simply, using
execute and a named parsed query would implicitly perform prepare per the
description above.

I'm not sure how different this is from writing views...though it can be
used for stuff like updates and deletes as well. You can, I think, already
get something similar by using set from current with a function...

David J.