Re: Delaying the planning of unnamed statements until Bind

Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.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