�ǡ����ѹ����βĻ���

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 �ȥꥬ������䤤��碌�Ǥ� �Ļ�ˤʤ�ޤ���