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
