Do docs miss information about timing of triggers?

On Thu, May 26, 2016 at 8:50 AM, Thomas Güttler <
guettliml@thomas-guettler.de> wrote:

I (and a team mate) guess that the docs miss information about the timing
of triggers,
which are not constraint triggers:

https://www.postgresql.org/docs/devel/static/sql-createtrigger.html

{{{
When the CONSTRAINT option is specified, this command creates a constraint
trigger. This is the same as a regular trigger except that the timing of
the trigger firing can be adjusted using SET CONSTRAINTS. Constraint
triggers must be AFTER ROW triggers on tables. They can be fired either at
the end of the statement causing the triggering event, or at the end of the
containing transaction; in the latter case they are said to be deferred. A
pending deferred-trigger firing can also be forced to happen immediately by
using SET CONSTRAINTS. Constraint triggers are expected to raise an
exception when the constraints they implement are violated.
}}}

OK, timing of constraint triggers is explained.

But I think the docs don't state the timing of normal AFTER triggers.

Or am I blind?

​Through omission. Constraint triggers can optionally be deferred - given
the specificity that means normal triggers cannot.

By the time a given statement has completed all relevant normal triggers
will have fired. The various timings of combinations of (before/after +
row/statement) are not explicitly documented though there doesn't seem to
be non-intuitive behavior going on.

​Maybe knowing why you are asking the question will help us to understand
if/how things could be improved.

David J.
​

​

"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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 05/26/2016 05:50 AM, Thomas Güttler wrote:

I (and a team mate) guess that the docs miss information about the
timing of triggers,
which are not constraint triggers:

https://www.postgresql.org/docs/devel/static/sql-createtrigger.html

{{{
When the CONSTRAINT option is specified, this command creates a
constraint trigger. This is the same as a regular trigger except that
the timing of the trigger firing can be adjusted using SET CONSTRAINTS.
Constraint triggers must be AFTER ROW triggers on tables. They can be
fired either at the end of the statement causing the triggering event,
or at the end of the containing transaction; in the latter case they are
said to be deferred. A pending deferred-trigger firing can also be
forced to happen immediately by using SET CONSTRAINTS. Constraint
triggers are expected to raise an exception when the constraints they
implement are violated.
}}}

OK, timing of constraint triggers is explained.

But I think the docs don't state the timing of normal AFTER triggers.

Or am I blind?

Look about seven paragraphs up from the one you show above.

Regards,
Thomas Güttler

--
Adrian Klaver
adrian.klaver@aklaver.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general