mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-15 08:20:16 +08:00
pg_trigger's index on tgrelid is replaced by a unique index on
(tgrelid, tgname). This provides an additional check on trigger name uniqueness per-table (which was already enforced by the code anyway). With this change, RelationBuildTriggers will read the triggers in order by tgname, since it's scanning using this index. Since a predictable trigger ordering has been requested for some time, document this behavior as a feature. Also document that rules fire in name order, since yesterday's changes to pg_rewrite indexing cause that too.
This commit is contained in:
Tom Lane
parent
87d00363cb
commit
201737168c
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.33 2002/03/22 19:20:39 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.34 2002/04/19 16:36:08 tgl Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -22,7 +22,7 @@ PostgreSQL documentation
|
||||
</refsynopsisdivinfo>
|
||||
<synopsis>
|
||||
CREATE RULE <replaceable class="parameter">name</replaceable> AS ON <replaceable class="parameter">event</replaceable>
|
||||
TO <replaceable class="parameter">object</replaceable> [ WHERE <replaceable class="parameter">condition</replaceable> ]
|
||||
TO <replaceable class="parameter">table</replaceable> [ WHERE <replaceable class="parameter">condition</replaceable> ]
|
||||
DO [ INSTEAD ] <replaceable class="parameter">action</replaceable>
|
||||
|
||||
where <replaceable class="PARAMETER">action</replaceable> can be:
|
||||
@ -48,7 +48,8 @@ NOTHING
|
||||
<term><replaceable class="parameter">name</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of a rule to create.
|
||||
The name of a rule to create. This must be distinct from the name
|
||||
of any other rule for the same table.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -63,14 +64,11 @@ NOTHING
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><replaceable class="parameter">object</replaceable></term>
|
||||
<term><replaceable class="parameter">table</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Object is either <replaceable class="parameter">table</replaceable>
|
||||
or <replaceable class="parameter">table</replaceable>.<replaceable
|
||||
class="parameter">column</replaceable>. (Currently, only the
|
||||
<replaceable class="parameter">table</replaceable> form is
|
||||
actually implemented.)
|
||||
The name (optionally schema-qualified) of the table or view the rule
|
||||
applies to.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -103,8 +101,7 @@ NOTHING
|
||||
Within the <replaceable class="parameter">condition</replaceable>
|
||||
and <replaceable class="PARAMETER">action</replaceable>, the special
|
||||
table names <literal>new</literal> and <literal>old</literal> may be
|
||||
used to refer to values in the referenced table (the
|
||||
<replaceable class="parameter">object</replaceable>).
|
||||
used to refer to values in the referenced table.
|
||||
<literal>new</literal> is valid in ON INSERT and ON UPDATE rules
|
||||
to refer to the new row being inserted or updated.
|
||||
<literal>old</literal> is valid in ON UPDATE and ON DELETE
|
||||
@ -159,7 +156,7 @@ CREATE
|
||||
accessed, inserted, updated, or deleted, there is an old instance (for
|
||||
selects, updates and deletes) and a new instance (for inserts and
|
||||
updates). All the rules for the given event type and the given target
|
||||
object (table) are examined, in an unspecified order. If the
|
||||
table are examined successively (in order by name). If the
|
||||
<replaceable class="parameter">condition</replaceable> specified in the
|
||||
WHERE clause (if any) is true, the
|
||||
<replaceable class="parameter">action</replaceable> part of the rule is
|
||||
@ -178,8 +175,7 @@ CREATE
|
||||
The <replaceable class="parameter">action</replaceable> part of the
|
||||
rule can consist of one or more queries. To write multiple queries,
|
||||
surround them with parentheses. Such queries will be performed in the
|
||||
specified order (whereas there are no guarantees about the execution
|
||||
order of multiple rules for an object). The <replaceable
|
||||
specified order. The <replaceable
|
||||
class="parameter">action</replaceable> can also be NOTHING indicating
|
||||
no action. Thus, a DO INSTEAD NOTHING rule suppresses the original
|
||||
query from executing (when its condition is true); a DO NOTHING rule
|
||||
@ -191,6 +187,20 @@ CREATE
|
||||
executes with the same command and transaction identifier as the user
|
||||
command that caused activation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is important to realize that a rule is really a query transformation
|
||||
mechanism, or query macro. The entire query is processed to convert it
|
||||
into a series of queries that include the rule actions. This occurs
|
||||
before evaluation of the query starts. So, conditional rules are
|
||||
handled by adding the rule condition to the WHERE clause of the action(s)
|
||||
derived from the rule. The above description of a rule as an operation
|
||||
that executes for each row is thus somewhat misleading. If you actually
|
||||
want an operation that fires independently for each physical row, you
|
||||
probably want to use a trigger not a rule. Rules are most useful for
|
||||
situations that call for transforming entire queries independently of
|
||||
the specific data being handled.
|
||||
</para>
|
||||
|
||||
<refsect2 id="R2-SQL-CREATERULE-3">
|
||||
<refsect2info>
|
||||
@ -202,7 +212,7 @@ CREATE
|
||||
<para>
|
||||
Presently, ON SELECT rules must be unconditional INSTEAD rules and must
|
||||
have actions that consist of a single SELECT query. Thus, an ON SELECT
|
||||
rule effectively turns the object table into a view, whose visible
|
||||
rule effectively turns the table into a view, whose visible
|
||||
contents are the rows returned by the rule's SELECT query rather than
|
||||
whatever had been stored in the table (if anything). It is considered
|
||||
better style to write a CREATE VIEW command than to create a real table
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.22 2002/01/20 22:19:56 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.23 2002/04/19 16:36:08 tgl Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -44,15 +44,8 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
|
||||
<term><replaceable class="parameter">name</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name to give the new trigger.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><replaceable class="parameter">table</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of an existing table.
|
||||
The name to give the new trigger. This must be distinct from the name
|
||||
of any other trigger for the same table.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -64,11 +57,32 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><replaceable class="parameter">table</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name (optionally schema-qualified) of the table the trigger is for.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><replaceable class="parameter">func</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
A user-supplied function.
|
||||
A user-supplied function that is declared as taking no arguments
|
||||
and returning type <literal>opaque</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><replaceable class="parameter">arguments</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
An optional comma-separated list of arguments to be provided to the
|
||||
function when the trigger is executed, along with the standard trigger
|
||||
data such as old and new tuple contents. The arguments are literal
|
||||
string constants. Simple names and numeric constants may be written
|
||||
here too, but they will all be converted to strings.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -130,6 +144,12 @@ CREATE
|
||||
after the event, all changes, including the last insertion, update,
|
||||
or deletion, are <quote>visible</quote> to the trigger.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If multiple triggers of the same kind are defined for the same event,
|
||||
they will be fired in alphabetical order by name.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<command>SELECT</command> does not modify any rows so you can not
|
||||
create <command>SELECT</command> triggers. Rules and views are more
|
||||
@ -262,6 +282,12 @@ CREATE TABLE distributors (
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
SQL99 specifies that multiple triggers should be fired in
|
||||
time-of-creation order. <productname>PostgreSQL</productname>
|
||||
uses name order, which was judged more convenient to work with.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.22 2002/04/01 22:36:06 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.23 2002/04/19 16:36:08 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="triggers">
|
||||
@ -14,8 +14,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.22 2002/04/01 22:36:06 tgl
|
||||
AFTER on INSERT, DELETE or UPDATE of a tuple as a trigger event.
|
||||
</para>
|
||||
|
||||
<sect1 id="trigger-create">
|
||||
<title>Trigger Creation</title>
|
||||
<sect1 id="trigger-definition">
|
||||
<title>Trigger Definition</title>
|
||||
|
||||
<para>
|
||||
If a trigger event occurs, the trigger manager (called by the Executor)
|
||||
@ -24,13 +24,17 @@ $Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.22 2002/04/01 22:36:06 tgl
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The trigger function must be defined before the trigger is created as a
|
||||
function taking no arguments and returning opaque. If the function is
|
||||
written in C, it must use the <quote>version 1</> function manager interface.
|
||||
The trigger function must be defined before the trigger itself can be
|
||||
created. The trigger function must be declared as a
|
||||
function taking no arguments and returning type <literal>opaque</>.
|
||||
(The trigger function receives its input through a TriggerData
|
||||
structure, not in the form of ordinary function arguments.)
|
||||
If the function is written in C, it must use the <quote>version 1</>
|
||||
function manager interface.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The syntax for creating triggers is as follows:
|
||||
The syntax for creating triggers is:
|
||||
|
||||
<programlisting>
|
||||
CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT | DELETE | UPDATE [ OR ... ] ]
|
||||
@ -48,9 +52,9 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the trigger is
|
||||
used if you ever have to delete the trigger.
|
||||
It is used as an argument to the <command>DROP TRIGGER</command> command.
|
||||
The trigger must have a name distinct from all other triggers on
|
||||
the same table. The name is needed
|
||||
if you ever have to delete the trigger.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -72,7 +76,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<term>UPDATE</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The next element of the command determines on what event(s) will trigger
|
||||
The next element of the command determines what event(s) will trigger
|
||||
the function. Multiple events can be specified separated by OR.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -82,7 +86,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<term><replaceable>relation</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The relation name determines which table the event applies to.
|
||||
The relation name indicates which table the event applies to.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -94,6 +98,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<para>
|
||||
The FOR EACH clause determines whether the trigger is fired for each
|
||||
affected row or before (or after) the entire statement has completed.
|
||||
Currently only the ROW case is supported.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -102,7 +107,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<term><replaceable>procedure</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The procedure name is the function called.
|
||||
The procedure name is the function to be called.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -112,23 +117,23 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<listitem>
|
||||
<para>
|
||||
The arguments passed to the function in the TriggerData structure.
|
||||
The purpose of passing arguments to the function is to allow different
|
||||
This is either empty or a list of one or more simple literal
|
||||
constants (which will be passed to the function as strings).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The purpose of including arguments in the trigger definition
|
||||
is to allow different
|
||||
triggers with similar requirements to call the same function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Also, <replaceable>procedure</replaceable>
|
||||
may be used for triggering different relations (these
|
||||
functions are named as <firstterm>general trigger functions</>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 <quote>last updated</>
|
||||
function if used in an UPDATE event.
|
||||
As an example, there could be a generalized trigger
|
||||
function that takes as its arguments two field names and puts the
|
||||
current user in one and the current timestamp in the other.
|
||||
Properly written, 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 fields,
|
||||
to automatically track creation of records in a transaction table for
|
||||
example. It could also be used to track last-update events if
|
||||
defined as an UPDATE trigger.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -136,8 +141,8 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Trigger functions return HeapTuple to the calling Executor. This
|
||||
is ignored for triggers fired after an INSERT, DELETE or UPDATE operation
|
||||
Trigger functions return a HeapTuple to the calling Executor. The return
|
||||
value is ignored for triggers fired AFTER an operation,
|
||||
but it allows BEFORE triggers to:
|
||||
|
||||
<itemizedlist>
|
||||
@ -150,33 +155,41 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
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.
|
||||
For INSERT and UPDATE triggers only, the returned tuple becomes the
|
||||
tuple which will be inserted or will replace the tuple 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 the same NEW tuple it is passed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
handler. This may be changed in the future.
|
||||
</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 name. In the case of BEFORE triggers,
|
||||
the possibly-modified tuple returned by each trigger becomes the input
|
||||
to the next trigger. If any BEFORE trigger returns NULL, the operation
|
||||
is abandoned and subsequent triggers are not fired.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 techniques to stop recursion (cascading) on itself...
|
||||
direct limitation on the number of cascade levels. It is possible for
|
||||
cascades to cause recursive invocation of the same trigger --- for
|
||||
example, an INSERT trigger might execute a query that inserts an
|
||||
additional tuple into the same table, causing the INSERT trigger to be
|
||||
fired again. It is the trigger programmer's
|
||||
responsibility to avoid infinite recursion in such scenarios.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -326,7 +339,7 @@ typedef struct TriggerData
|
||||
<para>
|
||||
is a 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
|
||||
interesting 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).
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/catalog/indexing.c,v 1.91 2002/04/18 20:01:09 tgl Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/catalog/indexing.c,v 1.92 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -74,7 +74,7 @@ char *Name_pg_shadow_indices[Num_pg_shadow_indices] =
|
||||
char *Name_pg_statistic_indices[Num_pg_statistic_indices] =
|
||||
{StatisticRelidAttnumIndex};
|
||||
char *Name_pg_trigger_indices[Num_pg_trigger_indices] =
|
||||
{TriggerRelidIndex, TriggerConstrNameIndex, TriggerConstrRelidIndex, TriggerOidIndex};
|
||||
{TriggerRelidNameIndex, TriggerConstrNameIndex, TriggerConstrRelidIndex, TriggerOidIndex};
|
||||
char *Name_pg_type_indices[Num_pg_type_indices] =
|
||||
{TypeNameNspIndex, TypeOidIndex};
|
||||
char *Name_pg_description_indices[Num_pg_description_indices] =
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
* Copyright (c) 1999-2001, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/comment.c,v 1.42 2002/04/18 20:01:09 tgl Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/comment.c,v 1.43 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -753,7 +753,7 @@ CommentTrigger(List *qualname, char *comment)
|
||||
Relation pg_trigger,
|
||||
relation;
|
||||
HeapTuple triggertuple;
|
||||
HeapScanDesc scan;
|
||||
SysScanDesc scan;
|
||||
ScanKeyData entry[2];
|
||||
Oid oid;
|
||||
|
||||
@ -774,17 +774,22 @@ CommentTrigger(List *qualname, char *comment)
|
||||
elog(ERROR, "you are not permitted to comment on trigger '%s' for relation '%s'",
|
||||
trigname, RelationGetRelationName(relation));
|
||||
|
||||
/* Fetch the trigger oid from pg_trigger */
|
||||
|
||||
/*
|
||||
* Fetch the trigger tuple from pg_trigger. There can be only one
|
||||
* because of the unique index.
|
||||
*/
|
||||
pg_trigger = heap_openr(TriggerRelationName, AccessShareLock);
|
||||
ScanKeyEntryInitialize(&entry[0], 0x0, Anum_pg_trigger_tgrelid,
|
||||
ScanKeyEntryInitialize(&entry[0], 0x0,
|
||||
Anum_pg_trigger_tgrelid,
|
||||
F_OIDEQ,
|
||||
ObjectIdGetDatum(RelationGetRelid(relation)));
|
||||
ScanKeyEntryInitialize(&entry[1], 0x0, Anum_pg_trigger_tgname,
|
||||
ScanKeyEntryInitialize(&entry[1], 0x0,
|
||||
Anum_pg_trigger_tgname,
|
||||
F_NAMEEQ,
|
||||
CStringGetDatum(trigname));
|
||||
scan = heap_beginscan(pg_trigger, 0, SnapshotNow, 2, entry);
|
||||
triggertuple = heap_getnext(scan, 0);
|
||||
scan = systable_beginscan(pg_trigger, TriggerRelidNameIndex, true,
|
||||
SnapshotNow, 2, entry);
|
||||
triggertuple = systable_getnext(scan);
|
||||
|
||||
/* If no trigger exists for the relation specified, notify user */
|
||||
|
||||
@ -794,7 +799,7 @@ CommentTrigger(List *qualname, char *comment)
|
||||
|
||||
oid = triggertuple->t_data->t_oid;
|
||||
|
||||
heap_endscan(scan);
|
||||
systable_endscan(scan);
|
||||
|
||||
/* Create the comments with the pg_trigger oid */
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v 1.3 2002/04/18 20:01:09 tgl Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v 1.4 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -2909,10 +2909,10 @@ update_ri_trigger_args(Oid relid,
|
||||
if (fk_scan)
|
||||
irel = index_openr(TriggerConstrRelidIndex);
|
||||
else
|
||||
irel = index_openr(TriggerRelidIndex);
|
||||
irel = index_openr(TriggerRelidNameIndex);
|
||||
|
||||
ScanKeyEntryInitialize(&skey[0], 0x0,
|
||||
1, /* always column 1 of index */
|
||||
1, /* column 1 of index in either case */
|
||||
F_OIDEQ,
|
||||
ObjectIdGetDatum(relid));
|
||||
idxtgscan = index_beginscan(irel, false, 1, skey);
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/trigger.c,v 1.113 2002/04/12 20:38:24 tgl Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/trigger.c,v 1.114 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -90,14 +90,15 @@ CreateTrigger(CreateTrigStmt *stmt)
|
||||
elog(ERROR, "permission denied");
|
||||
|
||||
/*
|
||||
* If trigger is a constraint, user trigger name as constraint name
|
||||
* If trigger is an RI constraint, use trigger name as constraint name
|
||||
* and build a unique trigger name instead.
|
||||
*/
|
||||
if (stmt->isconstraint)
|
||||
{
|
||||
constrname = stmt->trigname;
|
||||
snprintf(constrtrigname, sizeof(constrtrigname),
|
||||
"RI_ConstraintTrigger_%u", newoid());
|
||||
stmt->trigname = constrtrigname;
|
||||
sprintf(constrtrigname, "RI_ConstraintTrigger_%u", newoid());
|
||||
|
||||
if (stmt->constrrel != NULL)
|
||||
constrrelid = RangeVarGetRelid(stmt->constrrel, false);
|
||||
@ -139,15 +140,20 @@ CreateTrigger(CreateTrigStmt *stmt)
|
||||
}
|
||||
|
||||
/*
|
||||
* Scan pg_trigger for existing triggers on relation. NOTE that this
|
||||
* is cool only because we have AccessExclusiveLock on the relation,
|
||||
* so the trigger set won't be changing underneath us.
|
||||
* Scan pg_trigger for existing triggers on relation. We do this mainly
|
||||
* because we must count them; a secondary benefit is to give a nice
|
||||
* error message if there's already a trigger of the same name. (The
|
||||
* unique index on tgrelid/tgname would complain anyway.)
|
||||
*
|
||||
* NOTE that this is cool only because we have AccessExclusiveLock on the
|
||||
* relation, so the trigger set won't be changing underneath us.
|
||||
*/
|
||||
tgrel = heap_openr(TriggerRelationName, RowExclusiveLock);
|
||||
ScanKeyEntryInitialize(&key, 0, Anum_pg_trigger_tgrelid,
|
||||
ScanKeyEntryInitialize(&key, 0,
|
||||
Anum_pg_trigger_tgrelid,
|
||||
F_OIDEQ,
|
||||
ObjectIdGetDatum(RelationGetRelid(rel)));
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidIndex, true,
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndex, true,
|
||||
SnapshotNow, 1, &key);
|
||||
while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
|
||||
{
|
||||
@ -336,15 +342,20 @@ DropTrigger(Oid relid, const char *trigname)
|
||||
|
||||
/*
|
||||
* Search pg_trigger, delete target trigger, count remaining triggers
|
||||
* for relation. Note this is OK only because we have
|
||||
* AccessExclusiveLock on the rel, so no one else is creating/deleting
|
||||
* triggers on this rel at the same time.
|
||||
* for relation. (Although we could fetch and delete the target
|
||||
* trigger directly, we'd still have to scan the remaining triggers,
|
||||
* so we may as well do both in one indexscan.)
|
||||
*
|
||||
* Note this is OK only because we have AccessExclusiveLock on the rel,
|
||||
* so no one else is creating/deleting triggers on this rel at the same
|
||||
* time.
|
||||
*/
|
||||
tgrel = heap_openr(TriggerRelationName, RowExclusiveLock);
|
||||
ScanKeyEntryInitialize(&key, 0, Anum_pg_trigger_tgrelid,
|
||||
ScanKeyEntryInitialize(&key, 0,
|
||||
Anum_pg_trigger_tgrelid,
|
||||
F_OIDEQ,
|
||||
ObjectIdGetDatum(relid));
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidIndex, true,
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndex, true,
|
||||
SnapshotNow, 1, &key);
|
||||
while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
|
||||
{
|
||||
@ -409,10 +420,11 @@ RelationRemoveTriggers(Relation rel)
|
||||
bool found = false;
|
||||
|
||||
tgrel = heap_openr(TriggerRelationName, RowExclusiveLock);
|
||||
ScanKeyEntryInitialize(&key, 0, Anum_pg_trigger_tgrelid,
|
||||
ScanKeyEntryInitialize(&key, 0,
|
||||
Anum_pg_trigger_tgrelid,
|
||||
F_OIDEQ,
|
||||
ObjectIdGetDatum(RelationGetRelid(rel)));
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidIndex, true,
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndex, true,
|
||||
SnapshotNow, 1, &key);
|
||||
|
||||
while (HeapTupleIsValid(tup = systable_getnext(tgscan)))
|
||||
@ -462,7 +474,8 @@ RelationRemoveTriggers(Relation rel)
|
||||
/*
|
||||
* Also drop all constraint triggers referencing this relation
|
||||
*/
|
||||
ScanKeyEntryInitialize(&key, 0, Anum_pg_trigger_tgconstrrelid,
|
||||
ScanKeyEntryInitialize(&key, 0,
|
||||
Anum_pg_trigger_tgconstrrelid,
|
||||
F_OIDEQ,
|
||||
ObjectIdGetDatum(RelationGetRelid(rel)));
|
||||
tgscan = systable_beginscan(tgrel, TriggerConstrRelidIndex, true,
|
||||
@ -502,7 +515,7 @@ RelationBuildTriggers(Relation relation)
|
||||
{
|
||||
TriggerDesc *trigdesc;
|
||||
int ntrigs = relation->rd_rel->reltriggers;
|
||||
Trigger *triggers = NULL;
|
||||
Trigger *triggers;
|
||||
int found = 0;
|
||||
Relation tgrel;
|
||||
ScanKeyData skey;
|
||||
@ -511,6 +524,15 @@ RelationBuildTriggers(Relation relation)
|
||||
struct varlena *val;
|
||||
bool isnull;
|
||||
|
||||
triggers = (Trigger *) MemoryContextAlloc(CacheMemoryContext,
|
||||
ntrigs * sizeof(Trigger));
|
||||
|
||||
/*
|
||||
* Note: since we scan the triggers using TriggerRelidNameIndex,
|
||||
* we will be reading the triggers in name order, except possibly
|
||||
* during emergency-recovery operations (ie, IsIgnoringSystemIndexes).
|
||||
* This in turn ensures that triggers will be fired in name order.
|
||||
*/
|
||||
ScanKeyEntryInitialize(&skey,
|
||||
(bits16) 0x0,
|
||||
(AttrNumber) Anum_pg_trigger_tgrelid,
|
||||
@ -518,7 +540,7 @@ RelationBuildTriggers(Relation relation)
|
||||
ObjectIdGetDatum(RelationGetRelid(relation)));
|
||||
|
||||
tgrel = heap_openr(TriggerRelationName, AccessShareLock);
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidIndex, true,
|
||||
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndex, true,
|
||||
SnapshotNow, 1, &skey);
|
||||
|
||||
while (HeapTupleIsValid(htup = systable_getnext(tgscan)))
|
||||
@ -526,16 +548,9 @@ RelationBuildTriggers(Relation relation)
|
||||
Form_pg_trigger pg_trigger = (Form_pg_trigger) GETSTRUCT(htup);
|
||||
Trigger *build;
|
||||
|
||||
if (found == ntrigs)
|
||||
if (found >= ntrigs)
|
||||
elog(ERROR, "RelationBuildTriggers: unexpected record found for rel %s",
|
||||
RelationGetRelationName(relation));
|
||||
|
||||
if (triggers == NULL)
|
||||
triggers = (Trigger *) MemoryContextAlloc(CacheMemoryContext,
|
||||
sizeof(Trigger));
|
||||
else
|
||||
triggers = (Trigger *) repalloc(triggers,
|
||||
(found + 1) * sizeof(Trigger));
|
||||
build = &(triggers[found]);
|
||||
|
||||
build->tgoid = htup->t_data->t_oid;
|
||||
@ -730,6 +745,9 @@ equalTriggerDescs(TriggerDesc *trigdesc1, TriggerDesc *trigdesc2)
|
||||
* We need not examine the "index" data, just the trigger array
|
||||
* itself; if we have the same triggers with the same types, the
|
||||
* derived index data should match.
|
||||
*
|
||||
* As of 7.3 we assume trigger set ordering is significant in the
|
||||
* comparison; so we just compare corresponding slots of the two sets.
|
||||
*/
|
||||
if (trigdesc1 != NULL)
|
||||
{
|
||||
@ -740,21 +758,9 @@ equalTriggerDescs(TriggerDesc *trigdesc1, TriggerDesc *trigdesc2)
|
||||
for (i = 0; i < trigdesc1->numtriggers; i++)
|
||||
{
|
||||
Trigger *trig1 = trigdesc1->triggers + i;
|
||||
Trigger *trig2 = NULL;
|
||||
Trigger *trig2 = trigdesc2->triggers + i;
|
||||
|
||||
/*
|
||||
* We can't assume that the triggers are always read from
|
||||
* pg_trigger in the same order; so use the trigger OIDs to
|
||||
* identify the triggers to compare. (We assume here that the
|
||||
* same OID won't appear twice in either trigger set.)
|
||||
*/
|
||||
for (j = 0; j < trigdesc2->numtriggers; j++)
|
||||
{
|
||||
trig2 = trigdesc2->triggers + j;
|
||||
if (trig1->tgoid == trig2->tgoid)
|
||||
break;
|
||||
}
|
||||
if (j >= trigdesc2->numtriggers)
|
||||
if (trig1->tgoid != trig2->tgoid)
|
||||
return false;
|
||||
if (strcmp(trig1->tgname, trig2->tgname) != 0)
|
||||
return false;
|
||||
|
||||
74
src/backend/utils/cache/relcache.c
vendored
74
src/backend/utils/cache/relcache.c
vendored
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.161 2002/04/18 20:01:09 tgl Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.162 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -635,10 +635,10 @@ RelationBuildRuleLock(Relation relation)
|
||||
{
|
||||
MemoryContext rulescxt;
|
||||
MemoryContext oldcxt;
|
||||
HeapTuple pg_rewrite_tuple;
|
||||
Relation pg_rewrite_desc;
|
||||
TupleDesc pg_rewrite_tupdesc;
|
||||
SysScanDesc pg_rewrite_scan;
|
||||
HeapTuple rewrite_tuple;
|
||||
Relation rewrite_desc;
|
||||
TupleDesc rewrite_tupdesc;
|
||||
SysScanDesc rewrite_scan;
|
||||
ScanKeyData key;
|
||||
RuleLock *rulelock;
|
||||
int numlocks;
|
||||
@ -657,7 +657,7 @@ RelationBuildRuleLock(Relation relation)
|
||||
relation->rd_rulescxt = rulescxt;
|
||||
|
||||
/*
|
||||
* form an array to hold the rewrite rules (the array is extended if
|
||||
* allocate an array to hold the rewrite rules (the array is extended if
|
||||
* necessary)
|
||||
*/
|
||||
maxlocks = 4;
|
||||
@ -675,18 +675,22 @@ RelationBuildRuleLock(Relation relation)
|
||||
|
||||
/*
|
||||
* open pg_rewrite and begin a scan
|
||||
*
|
||||
* Note: since we scan the rules using RewriteRelRulenameIndex,
|
||||
* we will be reading the rules in name order, except possibly
|
||||
* during emergency-recovery operations (ie, IsIgnoringSystemIndexes).
|
||||
* This in turn ensures that rules will be fired in name order.
|
||||
*/
|
||||
pg_rewrite_desc = heap_openr(RewriteRelationName, AccessShareLock);
|
||||
pg_rewrite_tupdesc = RelationGetDescr(pg_rewrite_desc);
|
||||
pg_rewrite_scan = systable_beginscan(pg_rewrite_desc,
|
||||
RewriteRelRulenameIndex,
|
||||
criticalRelcachesBuilt,
|
||||
SnapshotNow,
|
||||
1, &key);
|
||||
rewrite_desc = heap_openr(RewriteRelationName, AccessShareLock);
|
||||
rewrite_tupdesc = RelationGetDescr(rewrite_desc);
|
||||
rewrite_scan = systable_beginscan(rewrite_desc,
|
||||
RewriteRelRulenameIndex,
|
||||
true, SnapshotNow,
|
||||
1, &key);
|
||||
|
||||
while (HeapTupleIsValid(pg_rewrite_tuple = systable_getnext(pg_rewrite_scan)))
|
||||
while (HeapTupleIsValid(rewrite_tuple = systable_getnext(rewrite_scan)))
|
||||
{
|
||||
Form_pg_rewrite rewrite_form = (Form_pg_rewrite) GETSTRUCT(pg_rewrite_tuple);
|
||||
Form_pg_rewrite rewrite_form = (Form_pg_rewrite) GETSTRUCT(rewrite_tuple);
|
||||
bool isnull;
|
||||
Datum ruleaction;
|
||||
Datum rule_evqual;
|
||||
@ -697,7 +701,7 @@ RelationBuildRuleLock(Relation relation)
|
||||
rule = (RewriteRule *) MemoryContextAlloc(rulescxt,
|
||||
sizeof(RewriteRule));
|
||||
|
||||
rule->ruleId = pg_rewrite_tuple->t_data->t_oid;
|
||||
rule->ruleId = rewrite_tuple->t_data->t_oid;
|
||||
|
||||
rule->event = rewrite_form->ev_type - '0';
|
||||
rule->attrno = rewrite_form->ev_attr;
|
||||
@ -705,9 +709,9 @@ RelationBuildRuleLock(Relation relation)
|
||||
|
||||
/* Must use heap_getattr to fetch ev_qual and ev_action */
|
||||
|
||||
ruleaction = heap_getattr(pg_rewrite_tuple,
|
||||
ruleaction = heap_getattr(rewrite_tuple,
|
||||
Anum_pg_rewrite_ev_action,
|
||||
pg_rewrite_tupdesc,
|
||||
rewrite_tupdesc,
|
||||
&isnull);
|
||||
Assert(!isnull);
|
||||
ruleaction_str = DatumGetCString(DirectFunctionCall1(textout,
|
||||
@ -717,13 +721,13 @@ RelationBuildRuleLock(Relation relation)
|
||||
MemoryContextSwitchTo(oldcxt);
|
||||
pfree(ruleaction_str);
|
||||
|
||||
rule_evqual = heap_getattr(pg_rewrite_tuple,
|
||||
rule_evqual = heap_getattr(rewrite_tuple,
|
||||
Anum_pg_rewrite_ev_qual,
|
||||
pg_rewrite_tupdesc,
|
||||
rewrite_tupdesc,
|
||||
&isnull);
|
||||
Assert(!isnull);
|
||||
rule_evqual_str = DatumGetCString(DirectFunctionCall1(textout,
|
||||
rule_evqual));
|
||||
rule_evqual));
|
||||
oldcxt = MemoryContextSwitchTo(rulescxt);
|
||||
rule->qual = (Node *) stringToNode(rule_evqual_str);
|
||||
MemoryContextSwitchTo(oldcxt);
|
||||
@ -741,8 +745,8 @@ RelationBuildRuleLock(Relation relation)
|
||||
/*
|
||||
* end the scan and close the attribute relation
|
||||
*/
|
||||
systable_endscan(pg_rewrite_scan);
|
||||
heap_close(pg_rewrite_desc, AccessShareLock);
|
||||
systable_endscan(rewrite_scan);
|
||||
heap_close(rewrite_desc, AccessShareLock);
|
||||
|
||||
/*
|
||||
* form a RuleLock and insert into relation
|
||||
@ -764,9 +768,13 @@ RelationBuildRuleLock(Relation relation)
|
||||
static bool
|
||||
equalRuleLocks(RuleLock *rlock1, RuleLock *rlock2)
|
||||
{
|
||||
int i,
|
||||
j;
|
||||
int i;
|
||||
|
||||
/*
|
||||
* As of 7.3 we assume the rule ordering is repeatable,
|
||||
* because RelationBuildRuleLock should read 'em in a
|
||||
* consistent order. So just compare corresponding slots.
|
||||
*/
|
||||
if (rlock1 != NULL)
|
||||
{
|
||||
if (rlock2 == NULL)
|
||||
@ -776,21 +784,9 @@ equalRuleLocks(RuleLock *rlock1, RuleLock *rlock2)
|
||||
for (i = 0; i < rlock1->numLocks; i++)
|
||||
{
|
||||
RewriteRule *rule1 = rlock1->rules[i];
|
||||
RewriteRule *rule2 = NULL;
|
||||
RewriteRule *rule2 = rlock2->rules[i];
|
||||
|
||||
/*
|
||||
* We can't assume that the rules are always read from
|
||||
* pg_rewrite in the same order; so use the rule OIDs to
|
||||
* identify the rules to compare. (We assume here that the
|
||||
* same OID won't appear twice in either ruleset.)
|
||||
*/
|
||||
for (j = 0; j < rlock2->numLocks; j++)
|
||||
{
|
||||
rule2 = rlock2->rules[j];
|
||||
if (rule1->ruleId == rule2->ruleId)
|
||||
break;
|
||||
}
|
||||
if (j >= rlock2->numLocks)
|
||||
if (rule1->ruleId != rule2->ruleId)
|
||||
return false;
|
||||
if (rule1->event != rule2->event)
|
||||
return false;
|
||||
|
||||
@ -37,7 +37,7 @@
|
||||
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* $Id: catversion.h,v 1.118 2002/04/18 20:01:10 tgl Exp $
|
||||
* $Id: catversion.h,v 1.119 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -53,6 +53,6 @@
|
||||
*/
|
||||
|
||||
/* yyyymmddN */
|
||||
#define CATALOG_VERSION_NO 200204181
|
||||
#define CATALOG_VERSION_NO 200204182
|
||||
|
||||
#endif
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* $Id: indexing.h,v 1.65 2002/04/18 20:01:10 tgl Exp $
|
||||
* $Id: indexing.h,v 1.66 2002/04/19 16:36:08 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -86,7 +86,7 @@
|
||||
#define StatisticRelidAttnumIndex "pg_statistic_relid_att_index"
|
||||
#define TriggerConstrNameIndex "pg_trigger_tgconstrname_index"
|
||||
#define TriggerConstrRelidIndex "pg_trigger_tgconstrrelid_index"
|
||||
#define TriggerRelidIndex "pg_trigger_tgrelid_index"
|
||||
#define TriggerRelidNameIndex "pg_trigger_tgrelid_tgname_index"
|
||||
#define TriggerOidIndex "pg_trigger_oid_index"
|
||||
#define TypeNameNspIndex "pg_type_typname_nsp_index"
|
||||
#define TypeOidIndex "pg_type_oid_index"
|
||||
@ -182,9 +182,11 @@ DECLARE_UNIQUE_INDEX(pg_rewrite_rel_rulename_index on pg_rewrite using btree(ev_
|
||||
DECLARE_UNIQUE_INDEX(pg_shadow_usename_index on pg_shadow using btree(usename name_ops));
|
||||
DECLARE_UNIQUE_INDEX(pg_shadow_usesysid_index on pg_shadow using btree(usesysid int4_ops));
|
||||
DECLARE_UNIQUE_INDEX(pg_statistic_relid_att_index on pg_statistic using btree(starelid oid_ops, staattnum int2_ops));
|
||||
/* This following index is not used for a cache and is not unique */
|
||||
DECLARE_INDEX(pg_trigger_tgconstrname_index on pg_trigger using btree(tgconstrname name_ops));
|
||||
/* This following index is not used for a cache and is not unique */
|
||||
DECLARE_INDEX(pg_trigger_tgconstrrelid_index on pg_trigger using btree(tgconstrrelid oid_ops));
|
||||
DECLARE_INDEX(pg_trigger_tgrelid_index on pg_trigger using btree(tgrelid oid_ops));
|
||||
DECLARE_UNIQUE_INDEX(pg_trigger_tgrelid_tgname_index on pg_trigger using btree(tgrelid oid_ops, tgname name_ops));
|
||||
DECLARE_UNIQUE_INDEX(pg_trigger_oid_index on pg_trigger using btree(oid oid_ops));
|
||||
DECLARE_UNIQUE_INDEX(pg_type_oid_index on pg_type using btree(oid oid_ops));
|
||||
DECLARE_UNIQUE_INDEX(pg_type_typname_nsp_index on pg_type using btree(typname name_ops, typnamespace oid_ops));
|
||||
|
||||
@ -899,7 +899,7 @@ delete from pktable where base1=2;
|
||||
ERROR: <unnamed> referential integrity violation - key in pktable still referenced from pktable
|
||||
-- fails (1,1) is being referenced (twice)
|
||||
update pktable set base1=3 where base1=1;
|
||||
ERROR: <unnamed> referential integrity violation - key in pktable still referenced from pktable
|
||||
ERROR: <unnamed> referential integrity violation - key referenced from pktable not found in pktable
|
||||
-- this sequence of two deletes will work, since after the first there will be no (2,*) references
|
||||
delete from pktable where base2=2;
|
||||
delete from pktable where base1=2;
|
||||
|
||||
Loading…
Reference in New Issue
Block a user