I just noticed that there is an inconsistency between the way that
PREPARE executes multiple queries (since PREPARE itself accepts
only one SQL statement, any such multiple queries must have been
generated by rule expansion) and the way that it is done in
pg_exec_query_string(). The latter will do a SetQuerySnapshot()
between actions of the rule, the former only does
CommandCounterIncrement().
If you're in a serializable transaction then there's no difference
in behavior. But in READ COMMITTED mode this means that later actions
in the rule may be able to see the effects of other transactions that
committed while earlier actions were running.
ISTM we had better make the behavior consistent between PREPARE and
interactive execution. But which one do we want? I could see an
argument that it'd be best for all the actions of a rule to see a
consistent snapshot of the state of other transactions; and not doing
the extra SetQuerySnapshot() calls would save some cycles.
But perhaps we had better stick to our historical behavior.
pg_exec_query_string has done a SetQuerySnapshot per query for a long
time, and I can't recall anyone ever complaining about it.
Come to think of it, SPI also does CommandCounterIncrement but not
SetQuerySnapshot between querytrees; therefore this inconsistency
also affects SPI-based operations such as PL functions.
Comments?
regards, tom lane
