Re: Re: Bug with STABLE function using the wrong snapshot (probably during planning)

Noah Misch <noah@leadboat.com> writes:
>> Some initial debugging by RhodiumToad on #postgresql led to the following observation: The error occurs only when
the"SELECT ... WHERE i = a_bar();" is being planned, not when it is being executed, with the snapshot being used to
planthe query apparently being too old to see the result of the preceding insert. 

> The simplest fix I can see is to have _SPI_prepare_plan() push/pop a new
> snapshot when analyze_requires_snapshot() returns true on the raw parse tree.
> That strategy can break down in the other direction if the caller is STABLE;
> consider this example:

Yes.  I'm of the opinion that we should not change this.  In general,
marking functions STABLE that have major side effects (such as throwing
errors) is not a good idea, and putting such things into WHERE clauses
is a worse one.  We explicitly do not guarantee anything about timing or
order of evaluation in WHERE clauses, because to do so would cripple the
planner's ability to optimize them.  So I think this is a "don't do
that" case rather than "we should try to make planning happen with the
same snapshot that will be used at execution" case.

            regards, tom lane