Re: read-only planner input
От | Tom Lane |
---|---|
Тема | Re: read-only planner input |
Дата | |
Msg-id | 6313.1111156564@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: read-only planner input (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: read-only planner input
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: