>
> First session:
> postgres=# create table t(id integer);
> CREATE TABLE
> postgres=# insert into t values (1);
> INSERT 0 1
> postgres=# begin;
> BEGIN
> postgres=# select count(*) from t;
> count
> -------
> 1
> (1 row)
>
> 1 row in the table. In another session, insert another row in t:
>
> postgres=# insert into t values (2);
> INSERT 0 1
>
> And, then, back to the first session, still inside the previous transaction:
>
> postgres=# select count(*) from t;
> count
> -------
> 2
> (1 row)
>
> That's how Read Committed behaved. You see changes commited by other
> transactions, even transactions started after yours. That has nothing to do
> with triggers.
Yes, this is exactly how document tells us. The outer statement
("top-level" statements from client session) is of course one of the
cases which satisfies the read committed isolation level rules. It's
easy to understand and well-documented.
But remind that I am talking about the embedded statements triggered
by the outer statement (which you cannot see them in explicit way, you
need to check whether some trigger be set, and what statements
contained in the trigger). That's the document doesn't clarify.
Theoretically and literally, the trigger should be considered as part
of the outer command, just like CTE and other forms of sub-query, but
in fact, it is not! Instead, the commands in trigger should be
considered as virtual "outer" commands, just like you inline the
trigger body after the outer command. So that's why I said trigger is
an exception, which break/extend the rule.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
