Skip to content

P
Postgres FD Implementation
Commit 91eb34e9 authored by Vadim B. Mikheev's avatar Vadim B. Mikheev
Browse files
Options

New edition by D'Arcy and me.

parent d75206fd
Hide whitespace changes
Inline Side-by-side
Showing with 262 additions and 226 deletions
doc/spi.txt
View file @ 91eb34e9
PostgreSQL Server Programming Interface
Server Programming Interface (SPI) is attempt to give users ability run
SQL-queries inside user-defined C-function. For lack of Procedural Language
(PL) in current version of PostgreSQL, SPI is only way to write server
stored procedures and triggers. In the future, SPI will be used as
"workhorse" for PL.
The Server Programming Interface (SPI) is an attempt to give users the
ability to run SQL-queries inside user-defined C-functions. Given the lack
of a proper Procedural Language (PL) in the current version of PostgreSQL,
SPI is only way to write server stored procedures and triggers. In the future
SPI will be used as the "workhorse" for PL.
Actually, SPI is just set of builtin interface functions to simplify
access to Parser/Planner/Optimizer and Executor. Also, SPI does some memory
management.
In fact, SPI is just set of builtin interface functions to simplify
access to the Parser, Planner, Optimizer and Executor. SPI also does some
memory management.
To avoid misunderstanding we'll use word "function" for SPI interface
functions and word "procedure" for user-defined C-functions using SPI.
To avoid misunderstanding we'll use the word "function" for SPI interface
functions and the word "procedure" for user-defined C-functions using SPI.
SPI procedures are always called by some (upper) Executor and SPI manager
uses Executor to run your queries. Other procedures may be called by
Executor running queries from your procedure.
SPI procedures are always called by some (upper) Executor and the SPI
manager uses the Executor to run your queries. Other procedures may be
called by the Executor running queries from your procedure.
Note, that if during execution of query from a procedure transaction will
be aborted then control will not be returned to your procedure - all work
will be rollbacked and server will wait for the next command from client.
It will be changed in the next versions.
Note, that if during execution of a query from a procedure the transaction
is be aborted then control will not be returned to your procedure - all work
will be rolled back and the server will wait for the next command from the
client. This will be changed in the future versions.
Other restrictions are unability to execute BEGIN, END and ABORT
(transaction control statements) and cursor operations.
These are also to be changed in future.
Other restrictions are the inability to execute BEGIN, END and ABORT
(transaction control statements) and cursor operations. This will also be
changed in future.
Interface functions
If successful, SPI functions returns non-negative result (either via
If successful, SPI functions return a non-negative result (either via
returned (int) value or in SPI_result global variable, as described below).
Otherwise, negative result will be returned.
On error, a negative result will be returned.
int SPI_connect (void)
Connects your procedure to SPI manager. Initializes SPI internal
Connects your procedure to the SPI manager. Initializes the SPI internal
structures for query execution and memory management.
You are to call this function if you need in execution of queries. Some
You should call this function if you will need to execute queries. Some
utility SPI functions may be called from un-connected procedures.
Returns:
......@@ -48,45 +48,47 @@ int SPI_connect (void)
SPI_OK_CONNECT if connected.
SPI_ERROR_CONNECT if not. You may get this error if SPI_connect() is
called from already connected procedure - e.g. if you directly call one
procedure from another connected one. Actually, while child procedure
will be able to use SPI, your parent procedure will not be able continue
use SPI after child returned (if SPI_finish() called by child). It's bad
practice.
called from an already connected procedure - e.g. if you directly call one
procedure from another connected one. Actually, while the child procedure
will be able to use SPI, your parent procedure will not be able to continue
to use SPI after the child returns (if SPI_finish() is called by the child).
It's bad practice.
int SPI_finish(void)
Dis-connects your procedure from SPI manager. Frees all memory
allocations made by your procedure via palloc() after SPI_connect().
Disconnects your procedure from the SPI manager and frees all memory
allocations made by your procedure via palloc() since the SPI_connect().
These allocations can't be used any more! See Memory management.
After SPI_finish() is called your procedure loses ability to run queries.
Server is in the same state as just before call to SPI_connect().
After SPI_finish() is called your procedure loses the ability to run
queries. The server is in the same state as just before the call to
SPI_connect().
Returns:
SPI_OK_FINISH if properly disconnected.
SPI_ERROR_UNCONNECTED if called from un-connected procedure. No problems
with this - it means that nothing was made by SPI manager.
SPI_ERROR_UNCONNECTED if called from an un-connected procedure. No problem
with this - it means that nothing was made by the SPI manager.
NOTE! SPI_finish() MUST be called by connected procedure or you may get
unpredictable results! But you are able to don't call SPI_finish() if you
abort transaction (via elog(WARN)).
unpredictable results! But you are able to skip the call to SPI_finish()
if you abort the transaction (via elog(WARN)).
int SPI_exec(char *query, int tcount)
Creates execution plan (parser+planner+optimizer) and executes query for
tcount tuples. Should be called from connected procedure. If tcount eq 0
then executes query for all tuples returned by query scan. Using tcount >
0 you may restrict number of tuples for which query will be executed:
Creates an execution plan (parser+planner+optimizer) and executes query
for tcount tuples. This should only be called from a connected procedure.
If tcount eq 0 then it executes the query for all tuples returned by the
query scan. Using tcount > 0 you may restrict the number of tuples for
which the query will be executed:
SPI_exec ("insert into _table_ select * from _table_", 5);
- at max 5 tuples will be inserted into _table_.
If execution of your query was successful then one of the next
If execution of your query was successful then one of the following
(non-negative) values will be returned:
SPI_OK_UTILITY if some utility (e.g. CREATE TABLE ...) was executed.
......@@ -97,13 +99,14 @@ int SPI_exec(char *query, int tcount)
SPI_OK_UPDATE if UPDATE was executed.
NOTE! You may pass many queries in one string or query string may be
re-written by RULEs. SPI_exec() returns result for last query executed.
re-written by RULEs. SPI_exec() returns the result for the last query
executed.
Actual number of tuples for which (last) query was executed is returned
in global variable SPI_processed (if not SPI_OK_UTILITY).
The actual number of tuples for which the (last) query was executed is
returned in the global variable SPI_processed (if not SPI_OK_UTILITY).
If SPI_OK_SELECT returned and SPI_processed > 0 then you may use global
pointer SPITupleTable *SPI_tuptable to access selected tuples:
pointer SPITupleTable *SPI_tuptable to access the selected tuples:
Structure SPITupleTable is defined in spi.h:
......@@ -115,47 +118,47 @@ int SPI_exec(char *query, int tcount)
HeapTuple *vals; /* tuples */
} SPITupleTable;
HeapTuple *vals is array of pointers to tuples. TupleDesc tupdesc is
tuple descriptor which you are to pass to SPI functions dealing with
HeapTuple *vals is an array of pointers to tuples. TupleDesc tupdesc is
a tuple descriptor which you may pass to SPI functions dealing with
tuples.
NOTE! Functions SPI_exec(), SPI_execp() and SPI_prepare() change both
SPI_processed and SPI_tuptable (just pointer, not context of structure)!
So, save theme in local procedure variables if you need.
SPI_processed and SPI_tuptable (just the pointer, not the contents of the
structure)! So, save them in local procedure variables if you need them.
Also NOTE, that SPI_finish() frees and makes all SPITupleTable-s
Also NOTE, that SPI_finish() frees and makes all SPITupleTables
unusable! (See Memory management).
SPI_exec() may return one of the next (negative) values:
SPI_exec() may return one of the following (negative) values:
SPI_ERROR_ARGUMENT if query is NULL or tcount < 0.
SPI_ERROR_UNCONNECTED if procedure is un-connected.
SPI_ERROR_UNCONNECTED if procedure is unconnected.
SPI_ERROR_COPY if COPY TO/FROM stdin.
SPI_ERROR_CURSOR if DECLARE/CLOSE CURSOR, FETCH.
SPI_ERROR_TRANSACTION if BEGIN/ABORT/END.
SPI_ERROR_OPUNKNOWN if type of query is unknown (this shouldn't occure).
SPI_ERROR_OPUNKNOWN if type of query is unknown (this shouldn't occur).
void *SPI_prepare(char *query, int nargs, Oid * argtypes)
Creates and returns execution plan (parser+planner+optimizer) but doesn't
execute query. Should be called from connected procedure.
Creates and returns an execution plan (parser+planner+optimizer) but doesn't
execute the query. Should only be called from a connected procedure.
nargs is number of parameters ($1 ... $<nargs> - like in SQL-functions),
*argtypes is array of parameter type OIDs.
nargs is number of parameters ($1 ... $<nargs> - as in SQL-functions),
*argtypes is an array of parameter type OIDs.
nargs may be 0 only if there is no any $1 in query.
nargs may be 0 only if there is not any $1 in query.
Execution of prepared execution plans is much faster sometimes... So this
feature may be useful if the same query will be executed may times.
Execution of prepared execution plans is sometimes much faster so this
feature may be useful if the same query will be executed many times.
NOTE! Plan returned by SPI_prepare() may be used only in current
NOTE! The plan returned by SPI_prepare() may be used only in current
invocation of procedure: SPI_finish() frees memory allocated for a plan.
See SPI_saveplan().
If successful, NOT NULL pointer will be returned. Otherwise, you'll get
NULL plan. In both cases SPI_result will be setted like value returned by
SPI_exec, but
a NULL plan. In both cases SPI_result will be set like the value returned
by SPI_exec, except
SPI_ERROR_ARGUMENT if query is NULL or nargs < 0 or nargs > 0 && argtypes
is NULL.
......@@ -163,24 +166,24 @@ void *SPI_prepare(char *query, int nargs, Oid * argtypes)
void *SPI_saveplan(void *plan)
Currently, there is no ability to store prepared plans in system catalog
and fetch them from there for execution. This will be implemented in
future versions.
Currently, there is no ability to store prepared plans in the system
catalog and fetch them from there for execution. This will be implemented
in future versions.
As work arround, there is ability to re-use prepared plans in the
consequent invocations of your procedure in current session.
As a work arround, there is the ability to reuse prepared plans in the
consequent invocations of your procedure in the current session.
SPI_saveplan() saves passed plan (prepared by SPI_prepare()) in memory
protected from free-ing by SPI_finish() and by transaction manager and
returns pointer to saved plan. You may preserve pointer returned in local
variable and always check is this pointer NULL or not to either prepare
plan or use already prepared plan in SPI_execp (see below).
SPI_saveplan() saves a passed plan (prepared by SPI_prepare()) in memory
protected from freeing by SPI_finish() and by the transaction manager and
returns a pointer to the saved plan. You may save the pointer returned in
a local variable. Always check if this pointer is NULL or not either when
preparing a plan or using an already prepared plan in SPI_execp (see below).
NOTE! If one of objects (relation, function, ...) referenced by prepared
plan will be dropped during your session (by your or another backend)
then results of SPI_execp (for this plan) will be unpredictable.
plan is dropped during your session (by your backend or another) then the
results of SPI_execp (for this plan) will be unpredictable.
If successful, NOT NULL returned. Otherwise, SPI_result setted to
If successful, NOT NULL is returned otherwise, SPI_result is set to
SPI_ERROR_ARGUMENT if plan is NULL.
SPI_ERROR_UNCONNECTED if procedure is un-connected.
......@@ -188,26 +191,26 @@ void *SPI_saveplan(void *plan)
int SPI_execp(void *plan, Datum * values, char *Nulls, int tcount)
Executes plan prepared by SPI_prepare() (or returned by SPI_saveplan()).
Should be called from connected procedure.
Executes a plan prepared by SPI_prepare() (or returned by SPI_saveplan()).
Should only be called from a connected procedure.
plan is pointer to execution plan, values points to actual parameter
plan is pointer to an execution plan, values points to actual parameter
values, Nulls - to array describing what parameters get NULLs ('n' -
NULL, ' ' - NOT NULL), tcount - number of tuples for which plan is to be
executed.
If Nulls is NULL then SPI assumes that all values (if any) are NOT NULL.
Returns value like SPI_exec, but
Returns the same value as SPI_exec, except
SPI_ERROR_ARGUMENT if plan is NULL or tcount < 0.
SPI_ERROR_PARAM if Values is NULL and plan prepared with some parameters.
If successful, SPI_tuptable and SPI_processed are initialized like by
If successful, SPI_tuptable and SPI_processed are initialized as in
SPI_exec().
All functions described below may be used by connected and un-connected
All functions described below may be used by connected and unconnected
procedures.
......@@ -215,26 +218,26 @@ HeapTuple SPI_copytuple(HeapTuple tuple)
Makes copy of tuple in upper Executor context (see Memory management).
If successful, NOT NULL returned. NULL (i.e. - error) will be returned
only if NULL passed in.
If successful, NOT NULL returned. NULL (i.e. - error) will be returned
only if NULL is passed in.
HeapTuple SPI_modifytuple(Relation rel, HeapTuple tuple, int natts,
int *attnum, Datum * Values, char *Nulls)
Modifies tuple of relation rel as described by the rest of arguments.
Modifies tuple of relation rel as described by the rest of the arguments.
natts is number of attribute numbers in attnum.
attnum is array of numbers of attributes which are to be changed.
Values are new values for attributes specified.
Nulls describes what of attributes specified are NULL (if Nulls is
natts is the number of attribute numbers in attnum.
attnum is an array of numbers of the attributes which are to be changed.
Values are new values for the attributes specified.
Nulls describes which of the attributes specified are NULL (if Nulls is
NULL then no NULLs).
If successful, NOT NULL pointer to new tuple returned. New tuple is
allocated in upper Executor context (see Memory management). Passed tuple
is not changed.
Returns NULL if failed and cause in SPI_result:
Returns NULL if failed with cause in SPI_result:
SPI_ERROR_ARGUMENT if rel is NULL or tuple is NULL or natts le 0 or
attnum is NULL or Values is NULL.
......@@ -244,26 +247,27 @@ HeapTuple SPI_modifytuple(Relation rel, HeapTuple tuple, int natts,
int SPI_fnumber(TupleDesc tupdesc, char *fname)
Returns attribute number for attribute with name as in fname.
Returns the attribute number for the attribute with name in fname.
tupdesc is tuple description.
Attribute numbers are 1-based.
Attribute numbers are 1 based.
Returns SPI_ERROR_NOATTRIBUTE if attribute not found.
Returns SPI_ERROR_NOATTRIBUTE if the named attribute is not found.
char *SPI_fname(TupleDesc tupdesc, int fnumber)
Returns (copy of) name of attribute with number fnumber.
Returns (a copy of) the name of the attribute with number fnumber.
Returns NULL and (SPI_ERROR_NOATTRIBUTE in SPI_result) if fnumber is
greater number of attributes in tupdesc or fnumber le 0.
greater than the number of attributes in tupdesc or fnumber le 0.
char *SPI_getvalue(HeapTuple tuple, TupleDesc tupdesc, int fnumber)
Returns external (string) representation of value of attribute fnumber in
tuple with descriptor tupdesc. Allocates memory as required by value.
Returns an external (string) representation of the value of attribute
fnumber in tuple with descriptor tupdesc. Allocates memory as required
by the value.
Returns NULL if
......@@ -275,8 +279,8 @@ char *SPI_getvalue(HeapTuple tuple, TupleDesc tupdesc, int fnumber)
Datum SPI_getbinval(HeapTuple tuple, TupleDesc tupdesc, int fnumber,
bool *isnull)
Returns value of attribute fnumber in tuple with descriptor tupdesc. This
is binary value in internal form. This is not copy!
Returns the value of attribute fnumber in the tuple with descriptor
tupdesc. This is a binary value in internal form. This is not a copy!
Returns NULL indicator in *isnull.
......@@ -285,7 +289,7 @@ Datum SPI_getbinval(HeapTuple tuple, TupleDesc tupdesc, int fnumber,
char *SPI_gettype(TupleDesc tupdesc, int fnumber)
Returns (copy of) type name for attribute fnumber.
Returns (a copy of) the type name for attribute fnumber.
Returns NULL (and SPI_ERROR_NOATTRIBUTE in SPI_result) if fnumber
is invalid.
......@@ -300,7 +304,7 @@ Oid SPI_gettypeid(TupleDesc tupdesc, int fnumber)
char *SPI_getrelname(Relation rel)
Returns (copy of) relation name of relation rel.
Returns (a copy of) the name of relation rel.
void *SPI_palloc (Size size)
......@@ -323,67 +327,71 @@ void SPI_pfree(void *pointer)
Server allocates memory in memory contexts in such way that allocations
made in one context may be freed by context destruction without affecting
allocations made in other contexts. There is way to choose some context as
current one. All allocations (via palloc(), etc) are made in current
context. You'll get unpredictable results if you'll try to free (or
reallocate) memory allocated not in current context.
allocations made in other contexts. All allocations (via palloc(), etc) are
made in the context which are chosen as current one. You'll get
unpredictable results if you'll try to free (or reallocate) memory allocated
not in current context.
Creation and switching between memory contexts are subject of SPI manager
memory management.
SPI procedures deal with two memory contexts: upper Executor memory
context and procedure memory context (if connected).
Before a procedure is connected to SPI manager current memory context is
upper Executor context. And so, all allocation made by procedure itself via
palloc()/repalloc() or by SPI utility functions before connection to SPI are
Before a procedure is connected to the SPI manager, current memory context
is upper Executor context so all allocation made by the procedure itself via
palloc()/repalloc() or by SPI utility functions before connecting to SPI are
made in this context.
After SPI_connect() is called current context is procedure one. All
After SPI_connect() is called current context is the procedure's one. All
allocations made via palloc()/repalloc() or by SPI utility functions (except
for SPI_copytuple(), SPI_modifytuple, SPI_palloc() and SPI_repalloc()) are
made in this context.
When a procedure dis-connects from SPI manager (via SPI_finish()) current
context is restored to upper Executor context and all allocations made in
procedure memory context are freed and can't be used any more!
When a procedure disconnects from the SPI manager (via SPI_finish()) the
current context is restored to the upper Executor context and all allocations
made in the procedure memory context are freed and can't be used any more!
If you want to return something to upper Executor then you have to
allocate memory for this in upper context!
If you want to return something to the upper Executor then you have to
allocate memory for this in the upper context!
SPI has no ability to automatically free allocations in upper Executor
context!
SPI has no ability to automatically free allocations in the upper Executor
context!
SPI automatically frees memory allocated during execution of a query when
this query is done!
this query is done!
Data changes visibility
PostgreSQL data changes visibility rule: during query execution data
changes made by query itself (via SQL-function, SPI-function, triggers)
are invisible to the query scan.
Data changes visibility
For example, in query
PostgreSQL data changes visibility rule: during a query execution, data
changes made by the query itself (via SQL-function, SPI-function, triggers)
are invisible to the query scan. For example, in query
INSERT INTO a SELECT * FROM a
tuples inserted are invisible for SELECT' scan.
But also note that
tuples inserted are invisible for SELECT' scan. In effect, this
duplicates the database table within itself (subject to unique index
rules, of course) without recursing.
changes made by query Q are visible by queries which are started after
query Q, no matter - are they started inside Q (during execution of Q) or
after Q is done.
Changes made by query Q are visible by queries which are started after
query Q, no matter whether they are started inside Q (during the execution
of Q) or after Q is done.
Last example of usage SPI function below demonstrates visibility rule.
The last example of the usage of SPI procedure below demonstrates the
visibility rule.
Examples
There are complex examples in contrib/spi and in
src/test/regress/regress.c.
There are more complex examples in in src/test/regress/regress.c and
in contrib/spi.
This is very simple example of SPI using. Function execq accepts
SQL-query in first arguments and tcount in second, executes query
using SPI_exec and returns number of tuples for which query executed:
This is a very simple example of SPI usage. The procedure execq accepts
an SQL-query in its first argument and tcount in its second, executes the
query using SPI_exec and returns the number of tuples for which the query
executed:
----------------------------------------------------------------------------
#include "executor/spi.h" /* this is what you need to work with SPI */
......@@ -430,7 +438,7 @@ execq(text *sql, int cnt)
}
----------------------------------------------------------------------------
Now, compile and create function:
Now, compile and create the function:
create function execq (text, int4) returns int4 as '...path_to_so' language 'c';
vac=> select execq('create table a (x int4)', 0);
......
doc/trigger.txt
View file @ 91eb34e9
PostgreSQL Trigger Programming Guide
For the lack of Procedural Language (PL) in current version of
PostgreSQL, there is only ability to specify call to a C-function as trigger
action.
Also, STATEMENT-level trigger events are not supported in current
version, and so you are only able to specify BEFORE | AFTER
INSERT|DELETE|UPDATE of a tuple as trigger event.
If trigger event occures, trigger manager (called by Executor)
initializes global structure TriggerData *CurrentTriggerData (described
below) and calls trigger function to handle event.
Trigger function must be created before trigger creation as function
not accepting any arguments and returns opaque.
Actually, there are two specific features in triggers handling.
First, in CREATE TRIGGER one may specify arguments for trigger
function (EXECUTE PROCEDURE tfunc (aa,'bb', 1)), and these arguments
will be passed to trigger function in CurrentTriggerData.
It allows to use single function for many triggers and process events in
different ways.
While the current version of PostgreSQL has various client interfaces
such as Perl, Tcl, Python and C, it lacks an actual Procedural Language
(PL). We hope to have a proper PL one day. In the meantime it is possible
to call C functions as trigger actions. Note that STATEMENT-level trigger
events are not supported in the current version. You can currently specify
BEFORE or AFTER on INSERT, DELETE or UPDATE of a tuple as a trigger event.
If a trigger event occurs, the trigger manager (called by the Executor)
initializes the global structure TriggerData *CurrentTriggerData (described
below) and calls the trigger function to handle the event.
The trigger function must be created before the trigger is created as a
function taking no arguments and returns opaque.
The syntax for creating triggers is as follows.
CREATE TRIGGER <trigger name> <BEFORE|AFTER> <INSERT|DELETE|UPDATE>
ON <relation name> FOR EACH <ROW|STATEMENT>
EXECUTE PROCEDURE <procedure name> (<function args>);
The name of the trigger is used if you ever have to delete the trigger.
It is used as an argument to the DROP TRIGGER command.
The next word determines whether the function is called before or after
the event.
The next element of the command determines on what event(s) will trigger
the function. Multiple events can be specified separated by OR.
The relation name determines which table the event applies to.
The FOR EACH statement determines whether the trigger is fired for each
affected row or before (or after) the entire statement has completed.
The procedure name is the C function called.
The args are passed to the function in the CurrentTriggerData structure.
The purpose of passing arguments to the function is to allow different
triggers with similar requirements to call the same function.
Also, function may be used for triggering different relations (these
functions are named as "general trigger functions").
Second, trigger function has to return HeapTuple to upper Executor.
No matter for triggers fired AFTER operation (INSERT, DELETE, UPDATE),
but it allows to BEFORE triggers:
- return NULL to skip operation for current tuple (and so tuple
will not be inserted/updated/deleted);
- return pointer to another tuple (INSERT and UPDATE only) which will be
inserted (as new version of updated tuple if UPDATE) instead of
original tuple.
Note, that there is no initialization performed by CREATE TRIGGER
handler. It will be changed in the future.
Also, if more than one trigger defined for the same event on the same
relation then order of trigger firing is unpredictable. It may be changed in
the future.
Also, if a trigger function executes SQL-queries (using SPI) then these
queries may fire triggers again. This is known as cascading of triggers.
There is no explicit limitation for number of cascade levels.
If a trigger is fired by INSERT and inserts new tuple in the same
relation then this trigger will be fired again. Currently, there is nothing
provided for synchronization (etc) of these cases. It may be changed. At
As example of using both features above, there could be a general
function that takes as its arguments two field names and puts the current
user in one and the current timestamp in the other. This allows triggers to
be written on INSERT events to automatically track creation of records in a
transaction table for example. It could also be used as a "last updated"
function if used in an UPDATE event.
Trigger functions return HeapTuple to the calling Executor. This
is ignored for triggers fired after an INSERT, DELETE or UPDATE operation
but it allows BEFORE triggers to:
- return NULL to skip the operation for the current tuple (and so the
tuple will not be inserted/updated/deleted);
- return a pointer to another tuple (INSERT and UPDATE only) which will
be inserted (as the new version of the updated tuple if UPDATE) instead
of original tuple.
Note, that there is no initialization performed by the CREATE TRIGGER
handler. This will be changed in the future. Also, if more than one trigger
is defined for the same event on the same relation, the order of trigger
firing is unpredictable. This may be changed in the future.
If a trigger function executes SQL-queries (using SPI) then these queries
may fire triggers again. This is known as cascading triggers. There is no
explicit limitation on the number of cascade levels.
If a trigger is fired by INSERT and inserts a new tuple in the same
relation then this trigger will be fired again. Currently, there is nothing
provided for synchronization (etc) of these cases but this may change. At
the moment, there is function funny_dup17() in the regress tests which uses
some technics to stop recursion (cascading) of itself...
some techniques to stop recursion (cascading) on itself...
Interaction with trigger manager
Interaction with the trigger manager
As it's mentioned above when function is called by trigger manager
structure TriggerData *CurrentTriggerData is NOT NULL and initialized. And
so, it's better to check CurrentTriggerData against being NULL in the
begining and set it to NULL just after fetching information - to prevent
calls to trigger function not from trigger manager.
As mentioned above, when function is called by the trigger manager,
structure TriggerData *CurrentTriggerData is NOT NULL and initialized. So
it is better to check CurrentTriggerData against being NULL at the start
and set it to NULL just after fetching the information to prevent calls to
a trigger function not from the trigger manager.
struct TriggerData is defined in src/include/commands/trigger.h:
......@@ -70,8 +97,8 @@ typedef struct TriggerData
} TriggerData;
tg_event
describes event for what function is called. You may use macros
to deal with tg_event:
describes event for which the function is called. You may use the
following macros to examine tg_event:
TRIGGER_FIRED_BEFORE(event) returns TRUE if trigger fired BEFORE;
TRIGGER_FIRED_AFTER(event) returns TRUE if trigger fired AFTER;
......@@ -84,23 +111,25 @@ tg_event
TRIGGER_FIRED_BY_UPDATE(event) returns TRUE if trigger fired by UPDATE.
tg_relation
is pointer to structure describing triggered relation. Look @
src/include/utils/rel.h about this structure. The most interest things
are tg_relation->rd_att (descriptor of relation tuples) and
tg_relation->rd_rel->relname (relation' name. This is not char*, but
NameData - use SPI_getrelname(tg_relation) to get char* to copy of name).
is pointer to structure describing the triggered relation. Look at
src/include/utils/rel.h for details about this structure. The most
interest things are tg_relation->rd_att (descriptor of the relation
tuples) and tg_relation->rd_rel->relname (relation's name. This is not
char*, but NameData. Use SPI_getrelname(tg_relation) to get char* if
you need a copy of name).
tg_trigtuple
is tuple (pointer) for which trigger is fired. This is tuple to being
inserted (if INSERT), deleted (if DELETE) or updated (if UPDATE).
is a pointer to the tuple for which the trigger is fired. This is the tuple
being inserted (if INSERT), deleted (if DELETE) or updated (if UPDATE).
If INSERT/DELETE then this is what you are to return to Executor if
you don't want to replace tuple with another one (INSERT) or skip
you don't want to replace tuple with another one (INSERT) or skip the
operation.
tg_newtuple
is pointer to new version of tuple if UPDATE and NULL if INSERT/DELETE.
This is what you are to return to Executor if UPDATE and you don't want
to replace tuple with another one or skip operation.
is a pointer to the new version of tuple if UPDATE and NULL if this is
for an INSERT or a DELETE. This is what you are to return to Executor if
UPDATE and you don't want to replace this tuple with another one or skip
the operation.
tg_trigger
is pointer to structure Trigger defined in src/include/utils/rel.h:
......@@ -116,45 +145,44 @@ typedef struct Trigger
char **tgargs;
} Trigger;
tgname is trigger' name, tgnargs is number of arguments in tgargs, tgargs
is array of pointers to arguments specified in CREATE TRIGGER. Other
members are for internal use.
tgname is the trigger's name, tgnargs is number of arguments in tgargs,
tgargs is an array of pointers to the arguments specified in the CREATE
TRIGGER statement. Other members are for internal use only.
Data changes visibility
PostgreSQL data changes visibility rule: during query execution data
changes made by query itself (via SQL-function, SPI-function, triggers)
are invisible to the query scan.
Visibility of Data Changes
For example, in query
PostgreSQL data changes visibility rule: during a query execution, data
changes made by the query itself (via SQL-function, SPI-function, triggers)
are invisible to the query scan. For example, in query
INSERT INTO a SELECT * FROM a
tuples inserted are invisible for SELECT' scan.
tuples inserted are invisible for SELECT' scan. In effect, this
duplicates the database table within itself (subject to unique index
rules, of course) without recursing.
But keep in mind notices about visibility in SPI documentation:
But keep in mind this notice about visibility in the SPI documentation:
changes made by query Q are visible by queries which are started after
query Q, no matter - are they started inside Q (during execution of Q) or
after Q is done.
Changes made by query Q are visible by queries which are started after
query Q, no matter whether they are started inside Q (during the
execution of Q) or after Q is done.
This is true for triggers as well. And so, though tuple being inserted
(tg_trigtuple) is not visible to queries in BEFORE trigger, this tuple (just
inserted) is visible to queries in AFTER trigger, and to queries in
BEFORE/AFTER triggers fired after this!
This is true for triggers as well so, though a tuple being inserted
(tg_trigtuple) is not visible to queries in a BEFORE trigger, this tuple
(just inserted) is visible to queries in an AFTER trigger, and to queries
in BEFORE/AFTER triggers fired after this!
Examples
There are complex examples in contrib/spi and in
src/test/regress/regress.c.
There are more complex examples in in src/test/regress/regress.c and
in contrib/spi.
This is very simple example of trigger usage. Function trigf reports
about number of tuples in triggered relation ttest and in trigger fired
BEFORE INSERT/UPDATE checks against is attribute x NULL and skips operations
for NULLs (ala NOT NULL implementation using triggers without aborting
transaction if NULL).
Here is a very simple example of trigger usage. Function trigf reports
the number of tuples in the triggered relation ttest and skips the
operation if the query attempts to insert NULL into x (i.e - it acts as a
NOT NULL constraint but doesn't abort the transaction).
----------------------------------------------------------------------------
#include "executor/spi.h" /* this is what you need to work with SPI */
......@@ -247,7 +275,7 @@ vac=> insert into ttest values (1);
NOTICE:trigf (fired before): there are 0 tuples in ttest
NOTICE:trigf (fired after ): there are 1 tuples in ttest
^^^^^^^^
remember about visibility
remember what we said about visibility.
INSERT 167793 1
vac=> select * from ttest;
x
......@@ -259,7 +287,7 @@ vac=> insert into ttest select x * 2 from ttest;
NOTICE:trigf (fired before): there are 1 tuples in ttest
NOTICE:trigf (fired after ): there are 2 tuples in ttest
^^^^^^^^
remember about visibility
remember what we said about visibility.
INSERT 167794 1
vac=> select * from ttest;
x
......@@ -288,7 +316,7 @@ NOTICE:trigf (fired after ): there are 1 tuples in ttest
NOTICE:trigf (fired before): there are 1 tuples in ttest
NOTICE:trigf (fired after ): there are 0 tuples in ttest
^^^^^^^^
remember about visibility
remember what we said about visibility.
DELETE 2
vac=> select * from ttest;
x
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment