Neil Conway <neilc@samurai.com> writes:
> Oliver Jowett wrote:
>> What happens if (for example) DateStyle changes between the two parses?
> I'm don't think recreating the plan from the query string changes this
> fundamentally -- the interaction between (for example) GUC variables and
> prepared plans will likely not be well-defined (which will be no worse
> than it is today).
It is well defined, because we insist that the gram.y transformation not
depend on any changeable state. So if we forced replan after a change
of DateStyle, the "right thing" would happen with either plain text or
raw parsetrees as the starting point.
There is a separate issue here of course, which is whether it's really
the "right thing" --- if the plan got through parsing the first time
then it's pretty likely that it would fail under a different datestyle.
But certainly we've seen requests for cached plans to respond to changes
in search_path, and I doubt you can make a principled distinction
between that and datestyle.
From a practical point of view, I suspect the path of least resistance
is to use plain text as the saved representation, because (a) it's
smaller and (b) IIRC we don't currently have a complete set of copyfuncs
for raw parsetree nodes.
regards, tom lane
