Yes, you are right.
But "after" the statement could mean before commit, too.
Why not add this?
Proposal:
When no CONSTRAINT option is specified, this command creates a normal trigger. They
get fired at the end of the statement (IMMEDIATE).
Regards,
Thomas Güttler
Am 26.05.2016 um 15:43 schrieb Tom Lane:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> On Thu, May 26, 2016 at 8:50 AM, Thomas GÃŒttler <
>> guettliml@thomas-guettler.de> wrote:
>>> OK, timing of constraint triggers is explained.
>>> But I think the docs don't state the timing of normal AFTER triggers.
>
>> âThrough omission.
>
> It's not *that* bad. See
> https://www.postgresql.org/docs/9.5/static/trigger-definition.html
>
> Triggers are also classified according to whether they fire before,
> after, or instead of the operation. These are referred to as BEFORE
> triggers, AFTER triggers, and INSTEAD OF triggers
> respectively. Statement-level BEFORE triggers naturally fire before
> the statement starts to do anything, while statement-level AFTER
> triggers fire at the very end of the statement. These types of
> triggers may be defined on tables or views. Row-level BEFORE triggers
> fire immediately before a particular row is operated on, while
> row-level AFTER triggers fire at the end of the statement (but before
> any statement-level AFTER triggers). ...
>
> regards, tom lane
>
--
Thomas Guettler http://www.thomas-guettler.de/
