pdf viewer dll for c# : How to add image to pdf in preview SDK software service wpf winforms azure dnn postgresql-9.4-A4105-part2730

Chapter 35. Extending SQL
An extension’s SQL script files can also contain lines beginning with
\echo
,which will be ignored
(treated as comments) by the extension mechanism. This provision is commonly used to throw an
error if the script file is fed to psql rather than being loaded via
CREATE EXTENSION
(see example
script below). Without that, users might accidentally load the extension’s contents as “loose” objects
rather than as an extension, a state of affairs that’s a bit tedious to recover from.
Whilethescriptfiles cancontainany characters allowedbythespecifiedencoding, controlfiles should
contain only plain ASCII, because there is no way for PostgreSQL to know what encoding a control
file is in. In practice this is only an issue if you want to use non-ASCII characters in the extension’s
comment. Recommended practice in that case is to not use the control file
comment
parameter, but
instead use
COMMENT ON EXTENSION
within a script file to set the comment.
35.15.2. Extension Relocatability
Users often wish to load the objects containedin an extension into a different schema than the exten-
sion’s author hadin mind. There are three supported levels of relocatability:
Afully relocatable extension can be moved into another schema at any time, even after it’s been
loaded into a database. This is done with the
ALTER EXTENSION SET SCHEMA
command, which
automatically renames all the member objects into the newschema. Normally, this is only possible
if the extension contains no internal assumptions about what schema any of its objects are in.
Also, the extension’s objects must all be in one schema to begin with (ignoring objects that do not
belong toanyschema, such as procedural languages). Mark a fully relocatableextensionby setting
relocatable = true
in its control file.
An extension might be relocatable during installation but not afterwards. This is typically the case
if the extension’s script file needs to reference the target schema explicitly, for example in setting
search_path
properties for SQL functions. For such an extension, set
relocatable = false
in its control file, and use
@extschema@
to refer to the target schema in the script file. All oc-
currences of this string will be replaced by the actual target schema’s name before the script is
executed. The user can set the target schema using the
SCHEMA
option of
CREATE EXTENSION
.
If the extension does not support relocation at all, set
relocatable = false
in its control file,
and also set
schema
to the name of the intended target schema. This willprevent use of the
SCHEMA
option of
CREATE EXTENSION
,unless it specifies the same schema named inthe control file. This
choice is typically necessary if the extension contains internal assumptions about schema names
that can’t be replaced by uses of
@extschema@
.The
@extschema@
substitution mechanism is
available in this case too, although it is of limited use since the schema name is determined by the
control file.
In all cases, the scriptfile willbe executed with search_pathinitially set to point to the target schema;
that is,
CREATE EXTENSION
does the equivalent of this:
SET LOCAL search_path TO @extschema@;
This allows the objects createdbythescript file to go intothe target schema. Thescript filecanchange
search_path
if it wishes, but that is generally undesirable.
search_path
is restored to its previous
setting upon completion of
CREATE EXTENSION
.
The target schema is determined bythe
schema
parameter inthecontrol file if that is given, otherwise
by the
SCHEMA
option of
CREATE EXTENSION
if that is given, otherwise the current default object
creationschema (the firstone in the caller’s
search_path
). When the control file
schema
parameter
is used, the target schema will be created if it doesn’t already exist, but in the other two cases it must
already exist.
978
How to add image to pdf in preview - insert images into PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sample C# code to add image, picture, logo or digital photo into PDF document page using PDF page editor control
add image pdf; adding images to pdf files
How to add image to pdf in preview - VB.NET PDF insert image library: insert images into PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide VB.NET Programmers How to Add Images in PDF Document
add photo to pdf form; how to add a picture to a pdf file
Chapter 35. Extending SQL
If any prerequisite extensions are listed in
requires
in the control file, their target schemas are
appended to the initial setting of
search_path
.This allows their objects to be visible to the new
extension’s script file.
Althougha non-relocatableextension cancontainobjects spread across multiple schemas, itis usually
desirable to place all the objects meant for external use into a single schema, which is considered
the extension’s target schema. Such an arrangement works conveniently with the default setting of
search_path
during creation of dependent extensions.
35.15.3. Extension Configuration Tables
Some extensions include configuration tables, which contain data that might be added or changed by
the user after installation of the extension. Ordinarily, if a table is part of an extension, neither the
table’s definition nor its content will be dumped by pg_dump. But that behavior is undesirable for a
configurationtable; any data changes made bythe user need to beincludedindumps, or theextension
will behave differently after a dump and reload.
To solve this problem, an extension’s script file can mark a table it has created as a configuration
table, which will cause pg_dump to include the table’s contents (not its definition) in dumps. To do
that, call the function
pg_extension_config_dump(regclass, text)
after creating the table,
for example
CREATE TABLE my_config (key text, value text);
SELECT pg_catalog.pg_extension_config_dump(’my_config’, ”);
Any number of tables can be marked this way.
When the second argument of
pg_extension_config_dump
is an empty string, the entire contents
of the table are dumped by pg_dump. This is usually only correct if the table is initially empty as
created by the extension script. If there is a mixture of initial data and user-provided data inthe table,
the second argument of
pg_extension_config_dump
provides a
WHERE
condition that selects the
data to be dumped. For example, you might do
CREATE TABLE my_config (key text, value text, standard_entry boolean);
SELECT pg_catalog.pg_extension_config_dump(’my_config’, ’WHERE NOT standard_entry’);
and then make sure that
standard_entry
is true only in the rows created by the extension’s script.
More complicated situations, such as initially-provided rows that might be modified by users, can
be handled by creating triggers on the configuration table to ensure that modified rows are marked
correctly.
You can alter the filter condition associated with a configuration table by calling
pg_extension_config_dump
again. (This would typically be useful in an extension update
script.) The only way to mark a table as no longer a configuration table is to dissociate it from the
extension with
ALTER EXTENSION ... DROP TABLE
.
Note that foreign key relationships between these tables will dictate the order in which the tables are
dumpedout by pg_dump. Specifically, pg_dump will attempt to dumpthe referenced-by table before
the referencing table. As the foreign key relationships are set up at CREATE EXTENSION time
(prior to data being loaded into the tables) circular dependencies are not supported. When circular
dependencies exist, the data will still be dumped out but the dump will not be able to be restored
directly and user intervention will be required.
979
C# WinForms Viewer: Load, View, Convert, Annotate and Edit PDF
Convert PDF to Tiff image (.tif, .tiff). • Convert PDF to HTML (.htm, .html). PDF Annotation. • Add sticky notes to PDF document in preview.
add a picture to a pdf document; add image to pdf online
C# WPF Viewer: Load, View, Convert, Annotate and Edit PDF
PDF to Tiff image (.tif, .tiff). • Convert PDF to HTML (.htm, .html). PDF Annotation. • Add sticky notes to PDF document. • Highlight PDF text in preview.
add png to pdf acrobat; adding images to pdf
Chapter 35. Extending SQL
35.15.4. Extension Updates
One advantage of the extension mechanism is that it provides convenient ways to manage updates to
the SQL commands that define an extension’s objects. This is done by associating a version name
or number with each released version of the extension’s installation script. In addition, if you want
users to be able to update their databases dynamically from one version to the next, you should
provide update scripts that make the necessary changes to go from one version to the next. Update
scripts have names following the pattern
extension
--
oldversion
--
newversion
.sql
(for example,
foo--1.0--1.1.sql
contains the commands to modify version
1.0
of extension
foo
into version
1.1
).
Given that a suitable update script is available, the command
ALTER EXTENSION UPDATE
will up-
date an installed extension to the specified new version. The update script is run in the same environ-
ment that
CREATE EXTENSION
provides for installation scripts: in particular,
search_path
is set up
in the same way, and any new objects created by the script are automatically added to the extension.
If an extension has secondary control files, the control parameters that are used for an update script
are those associated with the script’s target (new) version.
The update mechanism can be used to solve an important special case: converting a “loose” col-
lection of objects into an extension. Before the extension mechanism was added to PostgreSQL (in
9.1), many people wrote extension modules that simply created assorted unpackaged objects. Given
an existing database containing such objects, how can we convert the objects into a properly pack-
aged extension? Dropping them and then doing a plain
CREATE EXTENSION
is one way, but it’s
not desirable if the objects have dependencies (for example, if there are table columns of a data
type created by the extension). The way to fix this situation is to create an empty extension, then
use
ALTER EXTENSION ADD
to attach each pre-existing object to the extension, then finally cre-
ate any new objects that are in the current extension version but were not in the unpackaged re-
lease.
CREATE EXTENSION
supports this case with its
FROM old_version
option, which causes it
to not run the normal installation script for the target version, but instead the update script named
extension
--
old_version
--
target_version
.sql
.The choice of the dummy version name to use
as
old_version
is up to the extension author, though
unpackaged
is a common convention. If you
have multiple prior versions you need to be able to update into extension style, use multiple dummy
version names to identify them.
ALTER EXTENSION
is able to execute sequences of update script files to achieve a requested up-
date. For example, if only
foo--1.0--1.1.sql
and
foo--1.1--2.0.sql
are available,
ALTER
EXTENSION
will apply them in sequence if an update to version
2.0
is requested when
1.0
is cur-
rently installed.
PostgreSQL doesn’t assume anything about the properties of version names: for example, it does
not know whether
1.1
follows
1.0
.It just matches up the available version names and follows the
path that requires applying the fewest update scripts. (A version name can actually be any string that
doesn’t contain
--
or leadingor trailing
-
.)
Sometimes it is useful to provide “downgrade” scripts, for example
foo--1.1--1.0.sql
to allow
reverting the changes associated with version
1.1
.If you do that, be careful of the possibility that a
downgrade script might unexpectedly get applied because it yields a shorter path. The risky case is
where there is a “fast path” update script that jumps ahead several versions as well as a downgrade
script to the fast path’s start point. It might take fewer steps to apply the downgrade and then the fast
paththan to move ahead one versionat atime. If the downgradescript drops any irreplaceable objects,
this will yield undesirable results.
To check for unexpected update paths, use this command:
SELECT
*
FROM pg_extension_update_paths(’
extension_name
’);
980
How to C#: Preview Document Content Using XDoc.Word
C# DLLs for Word File Preview. Add references: Get Preview From File. You may get document preview image from an existing Word file in C#.net.
add photo to pdf preview; add photo to pdf
How to C#: Preview Document Content Using XDoc.PowerPoint
Add necessary XDoc.PowerPoint DLL libraries into your created C# application as You may get document preview image from an existing PowerPoint file in C#.net.
how to add jpg to pdf file; add image pdf acrobat
Chapter 35. Extending SQL
This shows each pair of distinct known version names for the specified extension, together with the
update path sequence thatwouldbe takento get from the source version to the target version, or
NULL
if there is no available update path. The pathis shown in textual form with
--
separators. You canuse
regexp_split_to_array(path,’--’)
if you prefer an array format.
35.15.5. Extension Example
Here is a complete example of an SQL-only extension, a two-element composite type that can store
anytype of valuein its slots, whicharenamed “k” and“v”. Non-text values are automatically coerced
to text for storage.
The script file
pair--1.0.sql
looks like this:
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION pair" to load this file. \quit
CREATE TYPE pair AS ( k text, v text );
CREATE OR REPLACE FUNCTION pair(anyelement, text)
RETURNS pair LANGUAGE SQL AS ’SELECT ROW($1, $2)::pair’;
CREATE OR REPLACE FUNCTION pair(text, anyelement)
RETURNS pair LANGUAGE SQL AS ’SELECT ROW($1, $2)::pair’;
CREATE OR REPLACE FUNCTION pair(anyelement, anyelement)
RETURNS pair LANGUAGE SQL AS ’SELECT ROW($1, $2)::pair’;
CREATE OR REPLACE FUNCTION pair(text, text)
RETURNS pair LANGUAGE SQL AS ’SELECT ROW($1, $2)::pair;’;
CREATE OPERATOR ~> (LEFTARG = text, RIGHTARG = anyelement, PROCEDURE = pair);
CREATE OPERATOR ~> (LEFTARG = anyelement, RIGHTARG = text, PROCEDURE = pair);
CREATE OPERATOR ~> (LEFTARG = anyelement, RIGHTARG = anyelement, PROCEDURE = pair);
CREATE OPERATOR ~> (LEFTARG = text, RIGHTARG = text, PROCEDURE = pair);
The control file
pair.control
looks like this:
# pair extension
comment = ’A key/value pair data type’
default_version = ’1.0’
relocatable = true
While you hardly need a makefile to install these two files into the correct directory, you could use a
Makefile
containing this:
EXTENSION = pair
DATA = pair--1.0.sql
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
981
VB.NET PDF File Compress Library: Compress reduce PDF size in vb.
enables compressing and decompressing in preview in ASP.NET to reduce or minimize original PDF document size Reduce image resources: Since images are usually or
add picture to pdf form; how to add photo to pdf in preview
How to C#: Preview Document Content Using XDoc.excel
Add necessary references: RasterEdge.Imaging.Basic.dll. Get Preview From File. You may get document preview image from an existing Excel file in C#.net.
add photo to pdf file; add jpg to pdf form
Chapter 35. Extending SQL
This makefile relies on PGXS, which is described in Section 35.16. The command
make install
will install the control and script files intothe correct directory as reportedby pg_config.
Once the files are installed, use the CREATE EXTENSION command to load the objects into any
particular database.
35.16. Extension Building Infrastructure
If youarethinking aboutdistributingyour PostgreSQL extensionmodules, settingup aportable build
system for them can be fairly difficult. Therefore the PostgreSQL installation provides a build infras-
tructure for extensions, called PGXS, so that simple extension modules can be built simply against an
already installed server. PGXS is mainly intended for extensions that include C code, although it can
be used for pure-SQL extensions too. Note that PGXS is not intended to be a universal build system
framework that can be used to build any software interfacing to PostgreSQL; it simply automates
common build rules for simple server extension modules. For more complicated packages, you might
need to write your own build system.
To use the PGXS infrastructure for your extension, you must write a simple makefile. In the makefile,
you need tosetsome variables and include the global PGXS makefile. Here is an example that builds
an extension module named
isbn_issn
,consisting of a shared library containing some C code, an
extension control file, a SQL script, and a documentation text file:
MODULES = isbn_issn
EXTENSION = isbn_issn
DATA = isbn_issn--1.0.sql
DOCS = README.isbn_issn
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
The last three lines should always be the same. Earlier in the file, you assign variables or add custom
make rules.
Set one of these three variables to specify what is built:
MODULES
list of shared-library objects to be built from source files with same stem (do not include library
suffixes in this list)
MODULE_big
ashared library to build from multiple source files (list object files in
OBJS
)
PROGRAM
an executable program to build (list object files in
OBJS
)
The following variables can also be set:
EXTENSION
extension name(s); for each name you must provide an
extension
.control
file, which will be
installed into
prefix
/share/extension
982
How to C#: Set Image Thumbnail in C#.NET
VB.NET How-to, VB.NET PDF, VB.NET Word following steps below, you can create an image viewer WinForm Open or create a new WinForms application, add necessary dll
adding images to a pdf document; adding an image to a pdf file
C# PDF remove image library: remove, delete images from PDF in C#.
Generally speaking, using well-designed APIs, C# developers can do following things. Remove Image from PDF Page Using C#. Add necessary references:
pdf insert image; acrobat insert image in pdf
Chapter 35. Extending SQL
MODULEDIR
subdirectory of
prefix
/share
intowhich DATA and DOCS files should be installed (if not set,
default is
extension
if
EXTENSION
is set, or
contrib
if not)
DATA
random files to install into
prefix
/share/$MODULEDIR
DATA_built
random files to install into
prefix
/share/$MODULEDIR
,whichneed to be built first
DATA_TSEARCH
random files to install under
prefix
/share/tsearch_data
DOCS
random files to install under
prefix
/doc/$MODULEDIR
SCRIPTS
script files (not binaries) to install into
prefix
/bin
SCRIPTS_built
script files (not binaries) to install into
prefix
/bin
,which need to be built first
REGRESS
list of regression test cases (without suffix), see below
REGRESS_OPTS
additional switches to pass to pg_regress
EXTRA_CLEAN
extra files to remove in
make clean
PG_CPPFLAGS
will be added to
CPPFLAGS
PG_LIBS
will be added to
PROGRAM
link line
SHLIB_LINK
will be added to
MODULE_big
link line
PG_CONFIG
path to pg_config program for the PostgreSQL installation to build against (typically just
pg_config
to use the first one in your
PATH
)
Put this makefile as
Makefile
in the directory which holds your extension. Then you can do
make
to compile, and then
make install
to install your module. By default, the extension is compiled
and installed for the PostgreSQL installation that corresponds to the first
pg_config
program found
in your
PATH
.You can use a different installation by setting
PG_CONFIG
to point to its
pg_config
program, either within the makefile or on the
make
command line.
You can also run
make
in a directory outside the source tree of your extension, if you want to keep
the build directory separate. This procedure is also called a VPATH build. Here’s how:
mkdir build_dir
983
Chapter 35. Extending SQL
cd build_dir
make -f /path/to/extension/source/tree/Makefile
make -f /path/to/extension/source/tree/Makefile install
Alternatively, you can set up a directory for a VPATH build in a similar way to how it is done for the
core code. One way to dothis is using the core script
config/prep_buildtree
.Once this has been
done you can build by setting the
make
variable
VPATH
like this:
make VPATH=/path/to/extension/source/tree
make VPATH=/path/to/extension/source/tree install
This procedure can work with a greater variety of directory layouts.
The scripts listed in the
REGRESS
variable are used for regression testing of your module, which
can be invoked by
make installcheck
after doing
make install
.For this to work you must
have a running PostgreSQL server. The script files listed in
REGRESS
must appear in a subdirectory
named
sql/
in your extension’s directory. These files must have extension
.sql
,which must not
be included in the
REGRESS
list in the makefile. For each test there should also be a file containing
the expected output in a subdirectory named
expected/
,with the same stem and extension
.out
.
make installcheck
executes each test script with psql, and compares the resulting output to the
matching expected file. Any differences will be written to the file
regression.diffs
in
diff -c
format. Note that trying to run a test that is missing its expected file will be reported as “trouble”, so
make sure you have all expected files.
Tip: Theeasiest way to create theexpectedfiles is to createempty files, thendoa test run (which
will of course report differences). Inspect the actual result files found in the
results/
directory,
then copy them to
expected/
if they match what you expect from the test.
984
Chapter 36. Triggers
This chapter provides general information about writing trigger functions. Trigger functions can be
written in most of the available procedural languages, including PL/pgSQL (Chapter 40), PL/Tcl
(Chapter 41), PL/Perl (Chapter 42), and PL/Python (Chapter 43). After reading this chapter, you
should consult the chapter for your favorite procedural language to find out the language-specific
details of writinga trigger in it.
It is also possible to write a trigger function in C, although most people find it easier touse one of the
procedurallanguages. It is not currently possible to write a trigger function in the plain SQL function
language.
36.1. Overview of Trigger Behavior
Atrigger is a specification thatthe database shouldautomatically execute a particular function when-
ever a certain type of operation is performed. Triggers can be attached to tables, views, and foreign
tables.
On tables and foreign tables, triggers can be defined to execute either before or after any
INSERT
,
UPDATE
,or
DELETE
operation, either once per modified row, or once per SQL statement.
UPDATE
triggers can moreover be set to fire only if certain columns are mentioned in the
SET
clause of the
UPDATE
statement. Triggers can also fire for
TRUNCATE
statements. If a trigger event occurs, the
trigger’s function is called at the appropriate time to handle the event. Foreign tables do not support
the TRUNCATE statement at all.
On views, triggers can be defined to execute instead of
INSERT
,
UPDATE
,or
DELETE
operations.
INSTEAD OF
triggers are fired once for each row that needs to be modified in the view. It is the
responsibility of the trigger’s function to perform the necessary modifications to the underlying base
tables and, where appropriate, returnthe modified row as it will appear in the view. Triggers onviews
can also be defined to execute once per SQL statement, before or after
INSERT
,
UPDATE
,or
DELETE
operations.
The trigger function mustbe defined before the trigger itself can be created. The trigger functionmust
be declared as a function taking no arguments and returning type
trigger
.(The trigger function
receives its input through a specially-passed
TriggerData
structure, not in the form of ordinary
function arguments.)
Oncea suitable trigger functionhas beencreated, the trigger is establishedwith CREATE TRIGGER.
The same trigger function can be used for multiple triggers.
PostgreSQL offers both per-rowtriggersandper-statement triggers. Witha per-rowtrigger, the trigger
functionis invoked oncefor each row thatis affectedbythe statement thatfiredthetrigger. In contrast,
aper-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 calledrow-level triggers and statement-level triggers, respectively. Triggers on
TRUNCATE
mayonly be definedat statement level. Onviews, triggers thatfire before or after may only be defined
at statement level, while triggers that fire instead of an
INSERT
,
UPDATE
,or
DELETE
may only be
defined at row level.
Triggers are also classified according to whether they fire before, after, or instead of the opera-
tion. These are referred to as
BEFORE
triggers,
AFTER
triggers, and
INSTEAD OF
triggers respec-
tively. Statement-level
BEFORE
triggers naturally fire before the statement starts todo anything, while
statement-level
AFTER
triggers fire at the very end of the statement. These types of triggers may be
985
Chapter 36. Triggers
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). These types of triggers may only be defined on tables and foreigntables. Row-
level
INSTEAD OF
triggers may only be defined on views, and fire immediately as each row in the
view is identified as needing to be operated on.
Trigger functions invoked by per-statement triggers should always return
NULL
.Trigger functions
invokedby per-rowtriggers canreturna tablerow(a value of type
HeapTuple
)tothecallingexecutor,
if they choose. A row-level trigger fired before an operation has the following choices:
It can return
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, modification, or deletion of
aparticular table row).
For row-level
INSERT
and
UPDATE
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.
Arow-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
NEW
row for
INSERT
and
UPDATE
triggers, the
OLD
row for
DELETE
triggers).
Arow-level
INSTEAD OF
trigger should either return
NULL
to indicate that it didnotmodify any data
from the view’s underlying base tables, or it should return the view row that was passed in (the
NEW
row for
INSERT
and
UPDATE
operations, or the
OLD
row for
DELETE
operations). A nonnull return
value is used to signal that the trigger performed the necessary data modifications in the view. This
will cause the count of the number of rows affected by the command to be incremented. For
INSERT
and
UPDATE
operations, the trigger maymodify the
NEW
row before returning it. This will change the
data returned by
INSERT RETURNING
or
UPDATE RETURNING
,and is useful when the view will not
showexactly the same data that was provided.
The return value is ignored for row-leveltriggers fired after an operation, and so theycanreturn
NULL
.
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
and
INSTEAD OF
triggers, the
possibly-modified row returned by each trigger becomes the input to the next trigger. If any
BEFORE
or
INSTEAD OF
trigger returns
NULL
,theoperation is abandoned for thatrowand subsequent triggers
are not fired (for that row).
Atrigger definition can also specify a Boolean
WHEN
condition, which will be tested to see whether
the trigger should be fired. In row-level triggers the
WHEN
condition can examine the old and/or new
values of columns of the row. (Statement-level triggers can also have
WHEN
conditions, although the
feature is not so useful for them.) In a
BEFORE
trigger, the
WHEN
condition is evaluated just before
the function is or would be executed, so using
WHEN
is not materially different from testing the same
condition at the beginning of the trigger function. However, in an
AFTER
trigger, the
WHEN
condition
is evaluated just after the row update occurs, and it determines whether an event is queued to fire
the trigger at the end of statement. So when an
AFTER
trigger’s
WHEN
condition does not return true,
it is not necessary to queue an event nor to re-fetch the row at end of statement. This can result in
significant speedups in statements that modify many rows, if the trigger only needs to be fired for a
few of the rows.
INSTEAD OF
triggers do not support
WHEN
conditions.
Typically, row-level
BEFORE
triggers are usedfor checking or modifyingthe data that willbe inserted
or updated. For example, a
BEFORE
trigger might be used to insert the current time into a
timestamp
column, or to check that two elements of the row are consistent. Row-level
AFTER
triggers are most
sensibly used to propagatetheupdates to other tables, or makeconsistencychecks againstother tables.
The reason for this division of labor is that an
AFTER
trigger can be certain it is seeing the final value
986
Chapter 36. Triggers
of the row, while a
BEFORE
trigger cannot; there might be other
BEFORE
triggers firingafter it. If you
have no specific reason to make a trigger
BEFORE
or
AFTER
,the
BEFORE
case is more efficient, since
the information about the operation doesn’t have to be saved until end of statement.
If a trigger function executes SQL commands then these commands might fire triggers again. This is
known as cascading triggers. There is no direct limitation on the number of cascade levels. It is pos-
sible for cascades to cause a recursive invocation of the same trigger; for example, an
INSERT
trigger
might execute a commandthat inserts an additional rowinto the same table, causing the
INSERT
trig-
ger to be fired again. It is the trigger programmer’s responsibility to avoid infinite recursion in such
scenarios.
When a trigger is being defined, arguments can be specified for it. The purpose of including argu-
ments in the trigger definition is to allow different triggers with similar requirements to call the same
function. As an example, there could be a generalized trigger function that takes as its arguments two
column names and puts the current user in one and the current time stamp in the other. Properly writ-
ten, this trigger function would be independent of the specific table it is triggering on. So the same
function could be used for
INSERT
events on any table with suitable columns, to automatically track
creationof records ina transaction table for example. It could also be used totrack last-update events
if defined as an
UPDATE
trigger.
Each programming language that supports triggers has its own method for making the trigger input
data available to the trigger function. This input data includes the type of trigger event (e.g.,
INSERT
or
UPDATE
)as well as any arguments that were listed in
CREATE TRIGGER
.For a row-level trigger,
the input data also includes the
NEW
row for
INSERT
and
UPDATE
triggers, and/or the
OLD
row for
UPDATE
and
DELETE
triggers. Statement-level triggers do not currently have any way to examine the
individual row(s) modifiedby the statement.
36.2. Visibility of Data Changes
If youexecute SQL commands in your trigger function, and these commands access the table that the
trigger is for, then you need to be aware of the data visibility rules, because they determine whether
these SQL commands will see the data change that the trigger is fired for. Briefly:
Statement-leveltriggers followsimple visibility rules:none of thechanges made bya statement are
visible to statement-level triggers that are invoked before the statement, whereas all modifications
are visible to statement-level
AFTER
triggers.
The data change (insertion, update, or deletion) causing the trigger to fire is naturally not visible to
SQL commands executed in a row-level
BEFORE
trigger, because it hasn’t happened yet.
However, SQL commands executed in a row-level
BEFORE
trigger will 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 can visit the rows in any order.
Similarly, a row-level
INSTEAD OF
trigger will see the effects of data changes made by previous
firings of
INSTEAD OF
triggers in the same outer command.
When a row-level
AFTER
trigger is fired, all data changes made by the outer command are already
complete, and are visible tothe invoked trigger function.
987
Documents you may be interested
Documents you may be interested