Re: Delaying the planning of unnamed statements until Bind

Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>
>>I guess that ExprState does not live long enough to be useful.
>
>
> Actually the opposite: it lasts too long, namely the entire execution of
> a query. I don't think there's any convenient way to reset it on the
> timescale appropriate for STABLE values (ie, once per scan, as opposed
> to once per query).

I think you misunderstand what I was suggesting. Given your earlier
clarification of what STABLE means, it isn't correct to mark expressions
involving a STABLE function as constant-at-execution-time, so those
results would not be cached. But there are still other expression trees
that would benefit, e.g. those involving an IMMUTABLE function with
parameterized arguments.

>>How about introducing a function modifier that provides stronger
>>guarantees than STABLE, along the lines of "immutable during execution
>>of a single SQL statement"?
>
> Why?

It's not directly useful currently, as there's no expression caching
going on. If there was expression caching, the stronger guarantees would
allow you to cache a wider range of expressions.

> I suspect that if we did have two flavors of STABLE, we'd just have a
> lot of people getting it wrong :-(. A big advantage of the current
> definition is exactly that it is pretty weak...

It seems quite hard to build a STABLE function that doesn't also satisfy
the stronger requirements. I can't think of how you'd do it as a SQL
function at all, off the top of my head. What sort of function were you
thinking of that is STABLE-safe but doesn't satisfy the stronger
requirements?

-O