Re: possible bug seen with -DCLOBBER_CACHE_ALWAYS and changing GUCs

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, Nov 30, 2011 at 5:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The result of parse analysis for that query is a stored date constant
>> (in a Const node) with a cast-to-text on top of it. The system is aware
>> that cast-date-to-text isn't immutable, so it doesn't try to fold the
>> cast operation. When you execute the query, it displays the date
>> constant using the now-current datestyle.

> Another thought: why does it execute the type input function (which is
> dependent on a GUC), but not the cast?

It's historical, see parse_coerce.c around line 210:

* XXX if the typinput function is not immutable, we really ought to
* postpone evaluation of the function call until runtime. But there
* is no way to represent a typinput function call as an expression
* tree, because C-string values are not Datums. (XXX This *is*
* possible as of 7.3, do we want to do it?)

(Of course, the parenthetical comment is a good deal newer than what
precedes it.)

However, I don't think this is the core issue. What is the core issue
is how many GUC settings we would like to save and reinstate for every
cached plan. We do that now for search_path because of the potential
security implications, but the costs of doing it for all of 'em seem
a tad daunting; not to mention that somebody is going to complain that
that's not the behavior he wanted.

regards, tom lane