Tom Lane wrote:
> It is well defined, because we insist that the gram.y transformation not
> depend on any changeable state.
That's my point -- whether we begin from the query string or the raw
parsetree shouldn't make a difference. By not well-defined, I meant that
if the user is changing GUC variables on the fly, they can't rely on
their prepared query being planned under any particular datestyle (or
search path, etc.), since they can't really predict when replanning will
take place (e.g. an sinval overflow could occur spontaneously and cause
all cached plans to be invalidated). This is similar to how search_path
and pl/pgsql works right now -- we'll use the search_path in effect when
the query is planned, which may or may not be what the user would expect.
-Neil