"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> I'm not sure exactly what you mean by "stable" here.
> Wasn't it you who defined *stable* as
> Cachable within a single command: given fixed input values, the
> result will not change if the function were to be repeatedly evaluated
> within a single SQL command; but the result could change over time.
Oh, *that* "stable" ;-)
Okay, I get your point now. You are right --- a function that
references a table that others might be concurrently changing
would not be stable under read-committed rules. (But you could
probably get away with marking it stable anyway.)
> I already mentioned an opinion in 2001/09/08.
> Both the command counters and the snapshots in a
> function should advance except the leading SELECT
> statements.
I do not like the idea of treating the first select in a function
differently from the rest. And such a rule wouldn't let you build
guaranteed-stable functions anyway; what if the outer query was
calling both your function, and another one that did cause the
snapshot to advance? The behavior of your function would then
vary depending on whether the other function was invoked or not.
regards, tom lane
