sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-28 00:03:23 -04:00
Code Issues Projects Releases Wiki Activity

doc: Minor wording changes

Browse Source 
From: Dmitry Igrishin <dmitigr@gmail.com>
This commit is contained in:
Peter Eisentraut 2016-04-29 13:03:58 -04:00
parent a03bda323b
commit 82881b2b43
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/sgml/trigger.sgml
View File

@ -125,11 +125,11 @@
If an <command>INSERT</command> contains an <literal>ON CONFLICT
DO UPDATE</> clause, it is possible that the effects of all
row-level <literal>BEFORE</> <command>INSERT</command> triggers
and all row-level BEFORE <command>UPDATE</command> triggers can
and all row-level <literal>BEFORE</literal> <command>UPDATE</command> triggers can
both be applied in a way that is apparent from the final state of
the updated row, if an <varname>EXCLUDED</> column is referenced.
There need not be an <varname>EXCLUDED</> column reference for
both sets of BEFORE row-level triggers to execute, though. The
both sets of row-level <literal>BEFORE</literal> triggers to execute, though. The
possibility of surprising outcomes should be considered when there
are both <literal>BEFORE</> <command>INSERT</command> and
<literal>BEFORE</> <command>UPDATE</command> row-level triggers
@ -327,7 +327,7 @@
<para>
Statement-level triggers follow simple visibility rules: none of
the changes made by a statement are visible to statement-level
triggers that are invoked before the statement, whereas all
<literal>BEFORE</literal> triggers, whereas all
modifications are visible to statement-level <literal>AFTER</>
triggers.
</para>