Picking out a specific point from the thread on prepared queries:
Currently, the handling of Parse/Bind on the unnamed statement seems to
go like this:
- Parse on the unnamed statement does analysis and rewriting but does
not plan, storing the query in a special memory context dedicated to
the unnamed statement
- Bind on the unnamed statement plans the query (using the supplied
parameters) and stores the plan back in the unnamed statement's context
I believe this could usefully (and transparently to clients) be changed
so that Bind on the unnamed statement does _not_ store the plan back in
the unnamed statement's context, but instead produces a plan which is
only used _for that specific portal_. Thus, it would promote the parameters
to constants before planning, knowing that the plan could only be run once;
this would, I believe, allow the planner to produce a plan that was
equivalent to that of a non-parameterized query.
This would hopefully remove all cases where it is currently necessary to
use PQexec rather than PQexecParams, such as where parameterized limits,
immutable functions of parameters, partial indexes etc. are involved.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
