Re: read-only planner input

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

In response to

Responses

Browse pgsql-hackers by date

  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