Re: STABLE vs. IMMUTABLE w.r.t. indexes - Mailing list pgsql-general

From Tom Lane
Subject Re: STABLE vs. IMMUTABLE w.r.t. indexes
Date
Msg-id 25763.1415045807@sss.pgh.pa.us
Whole thread Raw
In response to STABLE vs. IMMUTABLE w.r.t. indexes  (Moshe Jacobson <moshe@neadwerx.com>)
Responses Re: STABLE vs. IMMUTABLE w.r.t. indexes  (Moshe Jacobson <moshe@neadwerx.com>)
List pgsql-general
Moshe Jacobson <moshe@neadwerx.com> writes:
> The function pulls a GUC value and that's all it does. Is it safe to mark
> it IMMUTABLE?

No; such a function is by definition mutable.

> I noticed that if I updated the GUC variable and ran the
> query again, it worked as I would hope, with the new value of the function
> substituted. So it seems it would be safe, but I'd like to verify.

You might chance to get away with that as long as you never ever use the
function in a view or prepared query (including inside a plpgsql
function).  But it seems likely to bite you eventually.

> I'd also like to know why it wouldn't work if the function was STABLE:
> Since Postgres should know that it's not going to change over the course of
> the query, couldn't it substitute the value as well?

You have not shown us the context, but I suspect you are wishing that the
planner would assume that the function's result can't change between
planning and execution.  Unfortunately, it can.

            regards, tom lane


pgsql-general by date:

Previous
From: Igor Neyman
Date:
Subject: Re: [SPAM] - Performance of UPDATE SET = FROM vs UPDATE SET = (SELECT ...)
Next
From: pbj@cmicdo.com
Date:
Subject: Re: [SPAM] - Performance of UPDATE SET = FROM vs UPDATE SET = (SELECT ...)