Noah Misch <n...@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 plan the 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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
