Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
58ae3cf1
Commit
58ae3cf1
authored
21 years ago
by
Neil Conway
Browse files
Options
Downloads
Patches
Plain Diff
Minor improvements to the trigger documentation, and a few SGML fixes.
parent
5ad7d65d
Branches
Branches containing commit
Tags
Tags containing commit
No related merge requests found
Changes
2
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
doc/src/sgml/plpgsql.sgml
+8
-8
8 additions, 8 deletions
doc/src/sgml/plpgsql.sgml
doc/src/sgml/trigger.sgml
+66
-36
66 additions, 36 deletions
doc/src/sgml/trigger.sgml
with
74 additions
and
44 deletions
doc/src/sgml/plpgsql.sgml
+
8
−
8
View file @
58ae3cf1
<!--
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.3
2
200
3/11/30 05:45:22 momjian
Exp $
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.3
3
200
4/01/22 19:50:21 neilc
Exp $
-->
<chapter id="plpgsql">
...
...
@@ -729,7 +729,7 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
<para>
Using the <literal>RENAME</literal> declaration you can change the
name of a variable, record or row. This is primarily useful if
<
literal>NEW</literal> or <literal>OLD</literal
> should be
<
varname>NEW</varname> or <varname>OLD</varname
> should be
referenced by another name inside a trigger procedure. See also
<literal>ALIAS</literal>.
</para>
...
...
@@ -2176,7 +2176,7 @@ RAISE EXCEPTION ''Inexistent ID --> %'', user_id;
<para>
Data type <type>RECORD</type>; variable holding the new
database row for <command>INSERT</>/<command>UPDATE</> operations in row-level
triggers. This variable is
null
in statement-level triggers.
triggers. This variable is
<symbol>NULL</symbol>
in statement-level triggers.
</para>
</listitem>
</varlistentry>
...
...
@@ -2187,7 +2187,7 @@ RAISE EXCEPTION ''Inexistent ID --> %'', user_id;
<para>
Data type <type>RECORD</type>; variable holding the old
database row for <command>UPDATE</>/<command>DELETE</> operations in row-level
triggers. This variable is
null
in statement-level triggers.
triggers. This variable is
<symbol>NULL</symbol>
in statement-level triggers.
</para>
</listitem>
</varlistentry>
...
...
@@ -2281,9 +2281,9 @@ RAISE EXCEPTION ''Inexistent ID --> %'', user_id;
</para>
<para>
A trigger function must return either
null or a record/row value
having exactly the structure of the table the
trigger was fired
for.
A trigger function must return either
<symbol>NULL</symbol> or a
record/row value
having exactly the structure of the table the
trigger was fired
for.
</para>
<para>
...
...
This diff is collapsed.
Click to expand it.
doc/src/sgml/trigger.sgml
+
66
−
36
View file @
58ae3cf1
<!--
$PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.3
3
200
3/1
1/2
9
19:5
1:38 pgsql
Exp $
$PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.3
4
200
4/0
1/2
2
19:5
0:21 neilc
Exp $
-->
<chapter id="triggers">
...
...
@@ -45,50 +45,69 @@ $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.33 2003/11/29 19:51:38 pgsql Ex
</para>
<para>
Trigger functions return a table row (a value of type
<structname>HeapTuple</>) to the calling executor.
A trigger fired before an operation has the following choices:
There are two types of triggers: per-row triggers and
per-statement triggers. In a per-row trigger, the trigger function
is invoked once for every row that is affected by the statement
that fired the trigger. In contrast, a per-statement trigger is
invoked only once when an appropriate statement is executed,
regardless of the number of rows affected by that statement. In
particular, a statement that affects zero rows will still result
in the execution of any applicable per-statement triggers. These
two types of triggers are sometimes called <quote>row-level
triggers</quote> and <quote>statement-level triggers</quote>,
respectively.
</para>
<para>
Trigger functions invoked by per-statement triggers should always
return <symbol>NULL</symbol>. Trigger functions invoked by per-row
triggers can return a table row (a value of
type <structname>HeapTuple</structname>) to the calling executor,
if they choose. A row-level trigger fired before an operation has
the following choices:
<itemizedlist>
<listitem>
<para>
It can return a <symbol>NULL</> pointer to skip the operation
for the current row (and so the row will not be
inserted/updated/deleted).
It can return <symbol>NULL</> to skip the operation for the
current row. This instructs the executor to not perform the
row-level operation that invoked the trigger (the insertion or
modification of a particular table row).
</para>
</listitem>
<listitem>
<para>
For <command>INSERT</command>
and <command>UPDATE</command>
triggers only, the returned row
becomes the row that will
be inserted or will replace the row
being updated. This
allows the trigger function to modify the
row being inserted or
updated.
For
row-level
<command>INSERT</command>
and <command>UPDATE</command>
triggers only, the returned row
becomes the row that will
be inserted or will replace the row
being updated. This
allows the trigger function to modify the
row being inserted or
updated.
</para>
</listitem>
</itemizedlist>
A before trigger that does not intend to cause either of these
behaviors must be careful to return as its result the same row that was
passed in (that is, the NEW row for <command>INSERT</command> and
<command>UPDATE</command> triggers, the OLD row for
A row-level before trigger that does not intend to cause either of
these behaviors must be careful to return as its result the same
row that was passed in (that is, the <varname>NEW</varname> row
for <command>INSERT</command> and <command>UPDATE</command>
triggers, the <varname>OLD</varname> row for
<command>DELETE</command> triggers).
</para>
<para>
The return
value is ignored for triggers fired after an operation, and so
they may as well return <symbol>NULL</>.
The return value is ignored for row-level triggers fired after an
operation, and so they may as well return <symbol>NULL</>.
</para>
<para>
If more than one trigger is defined for the same event on the same
relation, the triggers will be fired in alphabetical order by trigger
name. In the case of before triggers, the possibly-modified row
returned by each trigger becomes the input to the next trigger.
If any before trigger returns a <symbol>NULL</> pointer, the
operation is abandoned and subsequent triggers are not fired.
relation, the triggers will be fired in alphabetical order by
trigger name. In the case of before triggers, the
possibly-modified row returned by each trigger becomes the input
to the next trigger. If any before trigger returns
<symbol>NULL</>, the operation is abandoned and subsequent
triggers are not fired.
</para>
<para>
...
...
@@ -134,30 +153,41 @@ $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.33 2003/11/29 19:51:38 pgsql Ex
is fired for. Briefly:
<itemizedlist>
<listitem>
<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
modifications are visible to statement-level after triggers.
</para>
</listitem>
<listitem>
<para>
The data change (insertion, update, or deletion) causing the
trigger
to fire is naturally
<emphasis>not</emphasis> visible to SQL commands executed in a
before trigger, because
it hasn't happened yet.
The data change (insertion, update, or deletion) causing the
trigger
to fire is naturally
<emphasis>not</emphasis> visible
to SQL commands executed in a row-level before trigger, because
it hasn't happened yet.
</para>
</listitem>
<listitem>
<para>
However, SQL commands executed in a
before trigger
<emphasis>will</emphasis> see the effects of data
changes
for rows previously processed in the same outer
command. This
requires caution, since the ordering of these
change events
is not in general predictable; a SQL command that
affects
multiple rows may visit the rows in any order.
However, SQL commands executed in a
row-level before
trigger
<emphasis>will</emphasis> see the effects of data
changes
for rows previously processed in the same outer
command. This
requires caution, since the ordering of these
change events
is not in general predictable; a SQL command that
affects
multiple rows may visit the rows in any order.
</para>
</listitem>
<listitem>
<para>
When an after trigger is fired, all data changes made by the outer
command are already complete, and are visible to executed SQL commands.
When a row-level after trigger is fired, all data changes made
by the outer command are already complete, and are visible to
the invoked trigger function.
</para>
</listitem>
</itemizedlist>
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment