On Monday, January 25, 2016, Vladimir Sitnikov <
sitnikov.vladimir@gmail.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.
