From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: read-only planner input |
Date: | 2005-03-18 14:36:04 |
Message-ID: | 6313.1111156564@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-03-18 15:13:02 | Re: "they only drink coffee at dec" |
Previous Message | Merlin Moncure | 2005-03-18 14:22:58 | Re: securing pg_proc |