> 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().
> 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.
Agreed.
Actions generated by a rule should definitely all get the same snapshot.
Thus I think we only want to CommandCounterIncrement inside one statement.
For multiple statement statements, the main issue is usually to gain
performance. So I guess we could also only CommandCounterIncrement there.
Especially since for (session local) FK PK issues that is sufficient.
Also in the light of implicit subtransactions I guess we will want to
start only one subtransaction per multi statement. Seems to fit well with
above.
> 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.
Whether rows that get committed during single statement execution should
be instantly visible (in read committed) is imho a different consideration.
It should definitely be handeled equivalenty between a rule action and a second
pass at a table (e.g. for a join).
Andreas