データ変更時の可視性

Postgres data changes visibility rule: during a query execution, data changes made by the query itself (via SQL-function, SPI-function, triggers) are invisible to the query scan. For example, in query

   INSERT INTO a SELECT * FROM a

tuples inserted are invisible for SELECT' scan. In effect, this duplicates the database table within itself (subject to unique index rules, of course) without recursing.

Postgres でのデータ変更時の可視規則は 以下の通りです。問い合わせ実行中、その問い合わせ自身によって（ SQL 関数、SPI 関数、トリガー経由で）なされたデータの変更は、その 問い合わせのスキャンに対して不可視となります。例えば、

   INSERT INTO a SELECT * FROM a

という問い合わせでは、挿入されたタプルは、SELECT スキャンに対して 不可視となります。このため、この問い合わせはデータベースのテーブルを 再帰処理することなく（もちろん、一意性インデックス規則に従って） 二重化します。

But keep in mind this notice about visibility in the SPI documentation:

   Changes made by query Q are visible by queries which are started after
   query Q, no matter whether they are started inside Q (during the
   execution of Q) or after Q is done.

しかし、SPI 文書中の可視性に関する次の注意書きを覚えておいて下 さい。

   問い合わせ Q によりなされる変更は、問い合わせ Q の後に開始した問
   い合わせに対しては可視です。この問い合わせが Q の内側で（ Q の実
   行中に）開始されたのか、Q の実行が終ってから開始されたのかについ
   ては問いません。

This is true for triggers as well so, though a tuple being inserted (tg_trigtuple) is not visible to queries in a BEFORE trigger, this tuple (just inserted) is visible to queries in an AFTER trigger, and to queries in BEFORE/AFTER triggers fired after this!

当然のことですが、挿入されるタプル（ tg_trigtuple ）は BEFORE トリガー中の問い合わせに対しては不可視となります。AFTER トリガ ー中の問い合わせに対してはこの（挿入されたばかりの）タプルは可 視に、そして、その後の BEFORE/AFTER トリガー中の問い合わせでは 可視になります！