rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/backend/commands/trigger.c

4403 lines
125 KiB
C
Raw Normal View History

Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
/*-------------------------------------------------------------------------
*
Change my-function-name-- to my_function_name, and optimizer renames.
1999-02-14 00:22:53 +01:00
* trigger.c
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* PostgreSQL TRIGGERs support code.
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
*
Update copyright for the year 2010.
2010-01-02 17:58:17 +01:00
* Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* $PostgreSQL: pgsql/src/backend/commands/trigger.c,v 1.263 2010/07/28 05:22:24 sriggs Exp $
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
*
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
*-------------------------------------------------------------------------
*/
#include "postgres.h"
This patch... 1. Removes the unnecessary "#define AbcRegProcedure 123"'s from pg_proc.h. 2. Changes those #defines to use the names already defined in fmgr.h. 3. Forces the make of fmgr.h in backend/Makefile instead of having it made as a dependency in access/common/Makefile *hack*hack*hack* 4. Rearranged the #includes to a less helter-skelter arrangement, also changing <file.h> to "file.h" to signify a non-system header. 5. Removed "pg_proc.h" from files where its only purpose was for the #defines removed in item #1. 6. Added "fmgr.h" to each file changed for completeness sake. Turns out that #6 was not necessary for some files because fmgr.h was being included in a roundabout way SIX levels deep by the first include. "access/genam.h" ->"access/relscan.h" ->"utils/rel.h" ->"access/strat.h" ->"access/skey.h" ->"fmgr.h" So adding fmgr.h really didn't add anything to the compile, hopefully just made it clearer to the programmer. S Darren.
1998-04-27 06:08:07 +02:00
#include "access/genam.h"
#include "access/heapam.h"
Restructure some header files a bit, in particular heapam.h, by removing some unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
2008-05-12 02:00:54 +02:00
#include "access/sysattr.h"
The following patch cleans up the deferred trigger mechanism. There is an unneeded memory context and some variables that are not used anymore. It's pretty trivial and the regression tests pass fine. There's no change in functionality, only deletion of unused code. I left an empty function because maybe I'll need it for nested transactions. Alvaro Herrera
2003-03-31 22:47:51 +02:00
#include "access/xact.h"
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
#include "catalog/catalog.h"
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
#include "catalog/dependency.h"
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
#include "catalog/indexing.h"
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
#include "catalog/pg_constraint.h"
This patch... 1. Removes the unnecessary "#define AbcRegProcedure 123"'s from pg_proc.h. 2. Changes those #defines to use the names already defined in fmgr.h. 3. Forces the make of fmgr.h in backend/Makefile instead of having it made as a dependency in access/common/Makefile *hack*hack*hack* 4. Rearranged the #includes to a less helter-skelter arrangement, also changing <file.h> to "file.h" to signify a non-system header. 5. Removed "pg_proc.h" from files where its only purpose was for the #defines removed in item #1. 6. Added "fmgr.h" to each file changed for completeness sake. Turns out that #6 was not necessary for some files because fmgr.h was being included in a roundabout way SIX levels deep by the first include. "access/genam.h" ->"access/relscan.h" ->"utils/rel.h" ->"access/strat.h" ->"access/skey.h" ->"fmgr.h" So adding fmgr.h really didn't add anything to the compile, hopefully just made it clearer to the programmer. S Darren.
1998-04-27 06:08:07 +02:00
#include "catalog/pg_proc.h"
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
#include "catalog/pg_trigger.h"
Add a bunch of pseudo-types to replace the behavior formerly associated with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
2002-08-22 02:01:51 +02:00
#include "catalog/pg_type.h"
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
#include "commands/dbcommands.h"
Provide an upgrade strategy for dump files containing functions declared with OPAQUE. CREATE LANGUAGE, CREATE TRIGGER, and CREATE TYPE will all accept references to functions declared with OPAQUE --- but they will issue a NOTICE, and will modify the function entries in pg_proc to have the preferred type-safe argument or result types instead of OPAQUE. Per recent pghackers discussions.
2002-09-21 20:39:26 +02:00
#include "commands/defrem.h"
This patch... 1. Removes the unnecessary "#define AbcRegProcedure 123"'s from pg_proc.h. 2. Changes those #defines to use the names already defined in fmgr.h. 3. Forces the make of fmgr.h in backend/Makefile instead of having it made as a dependency in access/common/Makefile *hack*hack*hack* 4. Rearranged the #includes to a less helter-skelter arrangement, also changing <file.h> to "file.h" to signify a non-system header. 5. Removed "pg_proc.h" from files where its only purpose was for the #defines removed in item #1. 6. Added "fmgr.h" to each file changed for completeness sake. Turns out that #6 was not necessary for some files because fmgr.h was being included in a roundabout way SIX levels deep by the first include. "access/genam.h" ->"access/relscan.h" ->"utils/rel.h" ->"access/strat.h" ->"access/skey.h" ->"fmgr.h" So adding fmgr.h really didn't add anything to the compile, hopefully just made it clearer to the programmer. S Darren.
1998-04-27 06:08:07 +02:00
#include "commands/trigger.h"
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
#include "executor/executor.h"
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
#include "executor/instrument.h"
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
#include "miscadmin.h"
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
#include "nodes/bitmapset.h"
Hack to make it possible to load CREATE CONSTRAINT TRIGGER commands that are missing the FROM clause (due to a long-ago pg_dump bug). Patch by Stephan Szabo, minor tweaking by Tom Lane.
2002-10-03 23:06:23 +02:00
#include "nodes/makefuncs.h"
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
#include "optimizer/clauses.h"
#include "optimizer/var.h"
#include "parser/parse_clause.h"
Functions live in namespaces. Qualified function names work, eg SELECT schema1.func2(...). Aggregate names can be qualified at the syntactic level, but the qualification is ignored for the moment.
2002-04-09 22:35:55 +02:00
#include "parser/parse_func.h"
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
#include "parser/parse_relation.h"
#include "parser/parsetree.h"
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
#include "pgstat.h"
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
#include "rewrite/rewriteManip.h"
Restructure some header files a bit, in particular heapam.h, by removing some unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
2008-05-12 02:00:54 +02:00
#include "storage/bufmgr.h"
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
#include "tcop/utility.h"
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
#include "utils/acl.h"
Final cleanup.
1999-07-16 07:00:38 +02:00
#include "utils/builtins.h"
Support hex-string input and output for type BYTEA. Both hex format and the traditional "escape" format are automatically handled on input. The output format is selected by the new GUC variable bytea_output. As committed, bytea_output defaults to HEX, which is an *incompatible change*. We will keep it this way for awhile for testing purposes, but should consider whether to switch to the more backwards-compatible default of ESCAPE before 8.5 is released. Peter Eisentraut
2009-08-04 18:08:37 +02:00
#include "utils/bytea.h"
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
#include "utils/fmgroids.h"
Final cleanup.
1999-07-16 07:00:38 +02:00
#include "utils/inval.h"
Mop-up some infelicities in new relation lookup handling.
2002-03-29 23:10:34 +01:00
#include "utils/lsyscache.h"
For some reason access/tupmacs.h has been #including utils/memutils.h, which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
2005-05-06 19:24:55 +02:00
#include "utils/memutils.h"
Rename snapmgmt.c/h to snapmgr.c/h, for consistency with other files. Per complaint from Tom Lane.
2008-03-26 19:48:59 +01:00
#include "utils/snapmgr.h"
Final cleanup.
1999-07-16 07:00:38 +02:00
#include "utils/syscache.h"
Move the HTSU_Result enum definition into snapshot.h, to avoid including tqual.h into heapam.h. This makes all inclusion of tqual.h explicit. I also sorted alphabetically the includes on some source files.
2008-03-26 22:10:39 +01:00
#include "utils/tqual.h"
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/* GUC variables */
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
int SessionReplicationRole = SESSION_REPLICATION_ROLE_ORIGIN;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
#define GetModifiedColumns(relinfo, estate) \
(rt_fetch((relinfo)->ri_RangeTableIndex, (estate)->es_range_table)->modifiedCols)
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/* Local function prototypes */
static void ConvertTriggerToFK(CreateTrigStmt *stmt, Oid funcoid);
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
static void InsertTrigger(TriggerDesc *trigdesc, Trigger *trigger, int indx);
static HeapTuple GetTupleForTrigger(EState *estate,
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
EPQState *epqstate,
pgindent run.
2003-08-04 02:43:34 +02:00
ResultRelInfo *relinfo,
ItemPointer tid,
TupleTableSlot **newSlot);
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
static bool TriggerEnabled(EState *estate, ResultRelInfo *relinfo,
Trigger *trigger, TriggerEvent event,
Bitmapset *modifiedCols,
HeapTuple oldtup, HeapTuple newtup);
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
static HeapTuple ExecCallTriggerFunc(TriggerData *trigdata,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
int tgindx,
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
FmgrInfo *finfo,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
Instrumentation *instr,
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
MemoryContext per_tuple_context);
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
static void AfterTriggerSaveEvent(EState *estate, ResultRelInfo *relinfo,
int event, bool row_trigger,
HeapTuple oldtup, HeapTuple newtup,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
List *recheckIndexes, Bitmapset *modifiedCols);
Mark functions as static and ifdef NOT_USED as appropriate.
2000-06-09 00:38:00 +02:00
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
Tweak CreateTrigger() so that the OID used in the name of an RI_ConstraintTrigger is the same OID assigned to the pg_trigger row. This reduces consumption of OIDs and may ease debugging.
2002-07-20 21:55:38 +02:00
/*
* Create a trigger. Returns the OID of the created trigger.
*
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
* queryString is the source text of the CREATE TRIGGER command.
* This must be supplied if a whenClause is specified, else it can be NULL.
*
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
* constraintOid, if nonzero, says that this trigger is being created
* internally to implement that constraint. A suitable pg_depend entry will
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* be made to link the trigger to that constraint. constraintOid is zero when
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* executing a user-entered CREATE TRIGGER command. (For CREATE CONSTRAINT
* TRIGGER, we build a pg_constraint entry internally.)
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
*
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
* indexOid, if nonzero, is the OID of an index associated with the constraint.
* We do nothing with this except store it into pg_trigger.tgconstrindid.
*
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* If isInternal is true then this is an internally-generated trigger.
* This argument sets the tgisinternal field of the pg_trigger entry, and
* if TRUE causes us to modify the given trigger name to ensure uniqueness.
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
*
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* When isInternal is not true we require ACL_TRIGGER permissions on the
* relation. For internal triggers the caller must apply any required
* permission checks.
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
*
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
* Note: can return InvalidOid if we decided to not create a trigger at all,
* but a foreign-key constraint. This is a kluge for backwards compatibility.
Tweak CreateTrigger() so that the OID used in the name of an RI_ConstraintTrigger is the same OID assigned to the pg_trigger row. This reduces consumption of OIDs and may ease debugging.
2002-07-20 21:55:38 +02:00
*/
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Oid
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
CreateTrigger(CreateTrigStmt *stmt, const char *queryString,
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
Oid constraintOid, Oid indexOid,
bool isInternal)
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
{
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
int16 tgtype;
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
int ncolumns;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
int2 *columns;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
int2vector *tgattr;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
Node *whenClause;
List *whenRtable;
char *qual;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
Datum values[Natts_pg_trigger];
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
bool nulls[Natts_pg_trigger];
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
Relation rel;
Restructure aclcheck error reporting to make permission-failure messages more uniform and internationalizable: the global array aclcheck_error_strings[] is gone in favor of a subroutine aclcheck_error(). Partial implementation of namespace-related permission checks --- not all done yet.
2002-04-27 05:45:03 +02:00
AclResult aclresult;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
Relation tgrel;
pgindent run.
2002-09-04 22:31:48 +02:00
SysScanDesc tgscan;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
ScanKeyData key;
Renaming cleanup, no pgindent yet.
1998-09-01 05:29:17 +02:00
Relation pgrel;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
HeapTuple tuple;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
Oid fargtypes[1]; /* dummy */
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
Oid funcoid;
Provide an upgrade strategy for dump files containing functions declared with OPAQUE. CREATE LANGUAGE, CREATE TRIGGER, and CREATE TYPE will all accept references to functions declared with OPAQUE --- but they will issue a NOTICE, and will modify the function entries in pg_proc to have the preferred type-safe argument or result types instead of OPAQUE. Per recent pghackers discussions.
2002-09-21 20:39:26 +02:00
Oid funcrettype;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Oid trigoid;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
char internaltrigname[NAMEDATALEN];
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
char *trigname;
Hack to make it possible to load CREATE CONSTRAINT TRIGGER commands that are missing the FROM clause (due to a long-ago pg_dump bug). Patch by Stephan Szabo, minor tweaking by Tom Lane.
2002-10-03 23:06:23 +02:00
Oid constrrelid = InvalidOid;
pgindent run.
2002-09-04 22:31:48 +02:00
ObjectAddress myself,
referenced;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
/*
* ShareRowExclusiveLock is sufficient to prevent concurrent write activity
* to the relation, and thus to lock out any operations that might want to
* fire triggers on the relation. If we had ON SELECT triggers we would
* need to take an AccessExclusiveLock to add one of those, just as we do
* with ON SELECT rules.
*/
rel = heap_openrv(stmt->relation, ShareRowExclusiveLock);
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
if (rel->rd_rel->relkind != RELKIND_RELATION)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a table",
RelationGetRelationName(rel))));
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
Checking to decide whether relations are system relations now depends on the namespace not the name; pg_ is not a reserved prefix for table names anymore. From Fernando Nasser.
2002-04-12 22:38:31 +02:00
if (!allowSystemTableMods && IsSystemRelation(rel))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
errmsg("permission denied: \"%s\" is a system catalog",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
RelationGetRelationName(rel))));
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
if (stmt->isconstraint && stmt->constrrel != NULL)
constrrelid = RangeVarGetRelid(stmt->constrrel, false);
Make CREATE CONSTRAINT TRIGGER check for REFERENCES privilege on both master and slave tables.
2002-08-18 13:20:05 +02:00
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
/* permission checks */
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (!isInternal)
Make CREATE CONSTRAINT TRIGGER check for REFERENCES privilege on both master and slave tables.
2002-08-18 13:20:05 +02:00
{
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
aclresult = pg_class_aclcheck(RelationGetRelid(rel), GetUserId(),
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
ACL_TRIGGER);
Make CREATE CONSTRAINT TRIGGER check for REFERENCES privilege on both master and slave tables.
2002-08-18 13:20:05 +02:00
if (aclresult != ACLCHECK_OK)
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(aclresult, ACL_KIND_CLASS,
RelationGetRelationName(rel));
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
if (OidIsValid(constrrelid))
Make CREATE CONSTRAINT TRIGGER check for REFERENCES privilege on both master and slave tables.
2002-08-18 13:20:05 +02:00
{
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
aclresult = pg_class_aclcheck(constrrelid, GetUserId(),
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
ACL_TRIGGER);
Make CREATE CONSTRAINT TRIGGER check for REFERENCES privilege on both master and slave tables.
2002-08-18 13:20:05 +02:00
if (aclresult != ACLCHECK_OK)
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(aclresult, ACL_KIND_CLASS,
get_rel_name(constrrelid));
Make CREATE CONSTRAINT TRIGGER check for REFERENCES privilege on both master and slave tables.
2002-08-18 13:20:05 +02:00
}
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
/* Compute tgtype */
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
TRIGGER_CLEAR_TYPE(tgtype);
if (stmt->before)
TRIGGER_SETT_BEFORE(tgtype);
if (stmt->row)
TRIGGER_SETT_ROW(tgtype);
Fix the just-reported problem that you can't specify all four trigger event types in CREATE TRIGGER. While at it, clean up the amazingly tedious and inextensible way that the trigger event type list was handled. Per report from Greg Sabino Mullane.
2009-06-18 03:27:02 +02:00
tgtype |= stmt->events;
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
Fix the just-reported problem that you can't specify all four trigger event types in CREATE TRIGGER. While at it, clean up the amazingly tedious and inextensible way that the trigger event type list was handled. Per report from Greg Sabino Mullane.
2009-06-18 03:27:02 +02:00
/* Disallow ROW-level TRUNCATE triggers */
if (TRIGGER_FOR_ROW(tgtype) && TRIGGER_FOR_TRUNCATE(tgtype))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("TRUNCATE FOR EACH ROW triggers are not supported")));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/*
* Parse the WHEN clause, if any
*/
if (stmt->whenClause)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
ParseState *pstate;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
RangeTblEntry *rte;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
List *varList;
ListCell *lc;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/* Set up a pstate to parse with */
pstate = make_parsestate(NULL);
pstate->p_sourcetext = queryString;
/*
* Set up RTEs for OLD and NEW references.
*
* 'OLD' must always have varno equal to 1 and 'NEW' equal to 2.
*/
rte = addRangeTableEntryForRelation(pstate, rel,
makeAlias("old", NIL),
false, false);
addRTEtoQuery(pstate, rte, false, true, true);
rte = addRangeTableEntryForRelation(pstate, rel,
makeAlias("new", NIL),
false, false);
addRTEtoQuery(pstate, rte, false, true, true);
/* Transform expression. Copy to be sure we don't modify original */
whenClause = transformWhereClause(pstate,
copyObject(stmt->whenClause),
"WHEN");
/*
* No subplans or aggregates, please
*/
if (pstate->p_hasSubLinks)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("cannot use subquery in trigger WHEN condition")));
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (pstate->p_hasAggs)
ereport(ERROR,
(errcode(ERRCODE_GROUPING_ERROR),
errmsg("cannot use aggregate function in trigger WHEN condition")));
if (pstate->p_hasWindowFuncs)
ereport(ERROR,
(errcode(ERRCODE_WINDOWING_ERROR),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("cannot use window function in trigger WHEN condition")));
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/*
* Check for disallowed references to OLD/NEW.
*
* NB: pull_var_clause is okay here only because we don't allow
* subselects in WHEN clauses; it would fail to examine the contents
* of subselects.
*/
varList = pull_var_clause(whenClause, PVC_REJECT_PLACEHOLDERS);
foreach(lc, varList)
{
Var *var = (Var *) lfirst(lc);
switch (var->varno)
{
case PRS2_OLD_VARNO:
if (!TRIGGER_FOR_ROW(tgtype))
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("statement trigger's WHEN condition cannot reference column values"),
parser_errposition(pstate, var->location)));
if (TRIGGER_FOR_INSERT(tgtype))
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("INSERT trigger's WHEN condition cannot reference OLD values"),
parser_errposition(pstate, var->location)));
/* system columns are okay here */
break;
case PRS2_NEW_VARNO:
if (!TRIGGER_FOR_ROW(tgtype))
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("statement trigger's WHEN condition cannot reference column values"),
parser_errposition(pstate, var->location)));
if (TRIGGER_FOR_DELETE(tgtype))
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("DELETE trigger's WHEN condition cannot reference NEW values"),
parser_errposition(pstate, var->location)));
if (var->varattno < 0 && TRIGGER_FOR_BEFORE(tgtype))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("BEFORE trigger's WHEN condition cannot reference NEW system columns"),
parser_errposition(pstate, var->location)));
break;
default:
/* can't happen without add_missing_from, so just elog */
elog(ERROR, "trigger WHEN condition cannot contain references to other relations");
break;
}
}
/* we'll need the rtable for recordDependencyOnExpr */
whenRtable = pstate->p_rtable;
qual = nodeToString(whenClause);
free_parsestate(pstate);
}
else
{
whenClause = NULL;
whenRtable = NIL;
qual = NULL;
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/*
* Find and validate the trigger function.
*/
funcoid = LookupFuncName(stmt->funcname, 0, fargtypes, false);
funcrettype = get_func_rettype(funcoid);
if (funcrettype != TRIGGEROID)
{
/*
* We allow OPAQUE just so we can load old dump files. When we see a
* trigger function declared OPAQUE, change it to TRIGGER.
*/
if (funcrettype == OPAQUEOID)
{
ereport(WARNING,
(errmsg("changing return type of function %s from \"opaque\" to \"trigger\"",
NameListToString(stmt->funcname))));
SetFunctionReturnType(funcoid, TRIGGEROID);
}
else
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("function %s must return type \"trigger\"",
NameListToString(stmt->funcname))));
}
/*
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* If the command is a user-entered CREATE CONSTRAINT TRIGGER command that
* references one of the built-in RI_FKey trigger functions, assume it is
* from a dump of a pre-7.3 foreign key constraint, and take steps to
* convert this legacy representation into a regular foreign key
* constraint. Ugly, but necessary for loading old dump files.
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
*/
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (stmt->isconstraint && !isInternal &&
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
list_length(stmt->args) >= 6 &&
(list_length(stmt->args) % 2) == 0 &&
RI_FKey_trigger_type(funcoid) != RI_TRIGGER_NONE)
{
/* Keep lock on target rel until end of xact */
heap_close(rel, NoLock);
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
ConvertTriggerToFK(stmt, funcoid);
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
return InvalidOid;
}
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
/*
* If it's a user-entered CREATE CONSTRAINT TRIGGER command, make a
* corresponding pg_constraint entry.
*/
if (stmt->isconstraint && !OidIsValid(constraintOid))
{
/* Internal callers should have made their own constraints */
Assert(!isInternal);
constraintOid = CreateConstraintEntry(stmt->trigname,
RelationGetNamespace(rel),
CONSTRAINT_TRIGGER,
stmt->deferrable,
stmt->initdeferred,
RelationGetRelid(rel),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
NULL, /* no conkey */
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
0,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
InvalidOid, /* no domain */
InvalidOid, /* no index */
InvalidOid, /* no foreign key */
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
NULL,
NULL,
NULL,
NULL,
0,
' ',
' ',
' ',
NULL, /* no exclusion */
NULL, /* no check constraint */
NULL,
NULL,
true, /* islocal */
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
0); /* inhcount */
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/*
* Generate the trigger's OID now, so that we can use it in the name if
* needed.
*/
tgrel = heap_open(TriggerRelationId, RowExclusiveLock);
trigoid = GetNewOid(tgrel);
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* If trigger is internally generated, modify the provided trigger name to
* ensure uniqueness by appending the trigger OID. (Callers will usually
* supply a simple constant trigger name in these cases.)
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
*/
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (isInternal)
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
snprintf(internaltrigname, sizeof(internaltrigname),
"%s_%u", stmt->trigname, trigoid);
trigname = internaltrigname;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
}
else
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
/* user-defined trigger; use the specified trigger name as-is */
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
trigname = stmt->trigname;
}
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Scan pg_trigger for existing triggers on relation. We do this only to
* give a nice error message if there's already a trigger of the same
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* name. (The unique index on tgrelid/tgname would complain anyway.) We
* can skip this for internally generated triggers, since the name
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* modification above should be sufficient.
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.
2002-04-19 18:36:08 +02:00
*
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* NOTE that this is cool only because we have ShareRowExclusiveLock on the
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.
2002-04-19 18:36:08 +02:00
* relation, so the trigger set won't be changing underneath us.
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
*/
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (!isInternal)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
ScanKeyInit(&key,
Anum_pg_trigger_tgrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
SnapshotNow, 1, &key);
while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
{
Form_pg_trigger pg_trigger = (Form_pg_trigger) GETSTRUCT(tuple);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (namestrcmp(&(pg_trigger->tgname), trigname) == 0)
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("trigger \"%s\" for relation \"%s\" already exists",
trigname, stmt->relation->relname)));
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
}
systable_endscan(tgscan);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
/*
* Build the new pg_trigger tuple.
*/
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
memset(nulls, false, sizeof(nulls));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
heap_fetch requires buffer pointer, must be released; heap_getnext no longer returns buffer pointer, can be gotten from scan; descriptor; bootstrap can create multi-key indexes; pg_procname index now is multi-key index; oidint2, oidint4, oidname are gone (must be removed from regression tests); use System Cache rather than sequential scan in many places; heap_modifytuple no longer takes buffer parameter; remove unused buffer parameter in a few other functions; oid8 is not index-able; remove some use of single-character variable names; cleanup Buffer variables usage and scan descriptor looping; cleaned up allocation and freeing of tuples; 18k lines of diff;
1998-08-19 04:04:17 +02:00
values[Anum_pg_trigger_tgrelid - 1] = ObjectIdGetDatum(RelationGetRelid(rel));
More functions updated to new fmgr style --- money, name, tid datatypes. We're reaching the mopup stage here (good thing too, this is getting tedious).
2000-08-03 18:35:08 +02:00
values[Anum_pg_trigger_tgname - 1] = DirectFunctionCall1(namein,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CStringGetDatum(trigname));
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
values[Anum_pg_trigger_tgfoid - 1] = ObjectIdGetDatum(funcoid);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
values[Anum_pg_trigger_tgtype - 1] = Int16GetDatum(tgtype);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
values[Anum_pg_trigger_tgenabled - 1] = CharGetDatum(TRIGGER_FIRES_ON_ORIGIN);
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
values[Anum_pg_trigger_tgisinternal - 1] = BoolGetDatum(isInternal);
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
values[Anum_pg_trigger_tgconstrrelid - 1] = ObjectIdGetDatum(constrrelid);
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
values[Anum_pg_trigger_tgconstrindid - 1] = ObjectIdGetDatum(indexOid);
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
values[Anum_pg_trigger_tgconstraint - 1] = ObjectIdGetDatum(constraintOid);
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
values[Anum_pg_trigger_tgdeferrable - 1] = BoolGetDatum(stmt->deferrable);
values[Anum_pg_trigger_tginitdeferred - 1] = BoolGetDatum(stmt->initdeferred);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
if (stmt->args)
{
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *le;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
char *args;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
int16 nargs = list_length(stmt->args);
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
int len = 0;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
foreach(le, stmt->args)
{
Clean up comments to be careful about the distinction between variable- width types and varlena types, since with the introduction of CSTRING as a more-or-less-real type, these concepts aren't identical. I've tried to use varlena consistently to denote datatypes with typlen = -1, ie, they have a length word and are potentially TOASTable; while the term variable width covers both varlena and cstring (and, perhaps, someday other types with other rules for computing the actual width). No code changes in this commit except for renaming a couple macros.
2002-08-25 19:20:01 +02:00
char *ar = strVal(lfirst(le));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
len += strlen(ar) + 4;
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
for (; *ar; ar++)
Fix \ handling
1997-10-02 15:52:29 +02:00
{
if (*ar == '\\')
len++;
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
args = (char *) palloc(len + 1);
copyObject() and equal() now know about all parse-time node types, including utility statements. Still can't copy or compare executor state, but at present that doesn't seem to be necessary. This makes it possible to execute most (all?) utility statements in plpgsql. Had to change parsetree representation of CreateTrigStmt so that it contained only legal Nodes, and not bare string constants.
2000-08-12 01:45:35 +02:00
args[0] = '\0';
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
foreach(le, stmt->args)
Fix \ handling
1997-10-02 15:52:29 +02:00
{
Clean up comments to be careful about the distinction between variable- width types and varlena types, since with the introduction of CSTRING as a more-or-less-real type, these concepts aren't identical. I've tried to use varlena consistently to denote datatypes with typlen = -1, ie, they have a length word and are potentially TOASTable; while the term variable width covers both varlena and cstring (and, perhaps, someday other types with other rules for computing the actual width). No code changes in this commit except for renaming a couple macros.
2002-08-25 19:20:01 +02:00
char *s = strVal(lfirst(le));
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
char *d = args + strlen(args);
Fix \ handling
1997-10-02 15:52:29 +02:00
while (*s)
{
if (*s == '\\')
*d++ = '\\';
*d++ = *s++;
}
copyObject() and equal() now know about all parse-time node types, including utility statements. Still can't copy or compare executor state, but at present that doesn't seem to be necessary. This makes it possible to execute most (all?) utility statements in plpgsql. Had to change parsetree representation of CreateTrigStmt so that it contained only legal Nodes, and not bare string constants.
2000-08-12 01:45:35 +02:00
strcpy(d, "\\000");
Fix \ handling
1997-10-02 15:52:29 +02:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
values[Anum_pg_trigger_tgnargs - 1] = Int16GetDatum(nargs);
bpchar, varchar, bytea, numeric are toastable --- if you initdb, which I did not force. I marked numeric as compressable-but-not-move-off-able, partly to test that storage mode and partly because I've got doubts that numerics are large enough to need external storage.
2000-07-29 05:26:51 +02:00
values[Anum_pg_trigger_tgargs - 1] = DirectFunctionCall1(byteain,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CStringGetDatum(args));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
else
{
values[Anum_pg_trigger_tgnargs - 1] = Int16GetDatum(0);
bpchar, varchar, bytea, numeric are toastable --- if you initdb, which I did not force. I marked numeric as compressable-but-not-move-off-able, partly to test that storage mode and partly because I've got doubts that numerics are large enough to need external storage.
2000-07-29 05:26:51 +02:00
values[Anum_pg_trigger_tgargs - 1] = DirectFunctionCall1(byteain,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CStringGetDatum(""));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
/* build column number array if it's a column-specific trigger */
ncolumns = list_length(stmt->columns);
if (ncolumns == 0)
columns = NULL;
else
{
ListCell *cell;
int i = 0;
columns = (int2 *) palloc(ncolumns * sizeof(int2));
foreach(cell, stmt->columns)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
char *name = strVal(lfirst(cell));
int2 attnum;
int j;
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
/* Lookup column name. System columns are not allowed */
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
attnum = attnameAttNum(rel, name, false);
if (attnum == InvalidAttrNumber)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errmsg("column \"%s\" of relation \"%s\" does not exist",
name, RelationGetRelationName(rel))));
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
/* Check for duplicates */
for (j = i - 1; j >= 0; j--)
{
if (columns[j] == attnum)
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_COLUMN),
errmsg("column \"%s\" specified more than once",
name)));
}
columns[i++] = attnum;
}
}
tgattr = buildint2vector(columns, ncolumns);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
values[Anum_pg_trigger_tgattr - 1] = PointerGetDatum(tgattr);
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/* set tgqual if trigger has WHEN clause */
if (qual)
values[Anum_pg_trigger_tgqual - 1] = CStringGetTextDatum(qual);
else
nulls[Anum_pg_trigger_tgqual - 1] = true;
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
tuple = heap_form_tuple(tgrel->rd_att, values, nulls);
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
Tweak CreateTrigger() so that the OID used in the name of an RI_ConstraintTrigger is the same OID assigned to the pg_trigger row. This reduces consumption of OIDs and may ease debugging.
2002-07-20 21:55:38 +02:00
/* force tuple to have the desired OID */
HeapTupleSetOid(tuple, trigoid);
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
/*
* Insert tuple into pg_trigger.
*/
Tweak CreateTrigger() so that the OID used in the name of an RI_ConstraintTrigger is the same OID assigned to the pg_trigger row. This reduces consumption of OIDs and may ease debugging.
2002-07-20 21:55:38 +02:00
simple_heap_insert(tgrel, tuple);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Restructure system-catalog index updating logic. Instead of having hardwired lists of index names for each catalog, use the relcache's mechanism for caching lists of OIDs of indexes of any table. This reduces the common case of updating system catalog indexes to a single line, makes it much easier to add a new system index (in fact, you can now do so on-the-fly if you want to), and as a nice side benefit improves performance a little. Per recent pghackers discussion.
2002-08-05 05:29:17 +02:00
CatalogUpdateIndexes(tgrel, tuple);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Some changes to prepare for LONG attributes. Jan
1999-12-16 23:20:03 +01:00
heap_freetuple(tuple);
Mega-commit to make heap_open/heap_openr/heap_close take an additional argument specifying the kind of lock to acquire/release (or 'NoLock' to do no lock processing). Ensure that all relations are locked with some appropriate lock level before being examined --- this ensures that relevant shared-inval messages have been processed and should prevent problems caused by concurrent VACUUM. Fix several bugs having to do with mismatched increment/decrement of relation ref count and mismatched heap_open/close (which amounts to the same thing). A bogus ref count on a relation doesn't matter much *unless* a SI Inval message happens to arrive at the wrong time, which is probably why we got away with this sloppiness for so long. Repair missing grab of AccessExclusiveLock in DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi. Recommend 'make clean all' after pulling this update; I modified the Relation struct layout slightly. Will post further discussion to pghackers list shortly.
1999-09-18 21:08:25 +02:00
heap_close(tgrel, RowExclusiveLock);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
pfree(DatumGetPointer(values[Anum_pg_trigger_tgname - 1]));
pfree(DatumGetPointer(values[Anum_pg_trigger_tgargs - 1]));
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
pfree(DatumGetPointer(values[Anum_pg_trigger_tgattr - 1]));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Update relation's pg_class entry. Crucial side-effect: other backends
* (and this one too!) are sent SI message to make them rebuild relcache
* entries.
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
pgrel = heap_open(RelationRelationId, RowExclusiveLock);
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCacheCopy1(RELOID,
ObjectIdGetDatum(RelationGetRelid(rel)));
heap_fetch requires buffer pointer, must be released; heap_getnext no longer returns buffer pointer, can be gotten from scan; descriptor; bootstrap can create multi-key indexes; pg_procname index now is multi-key index; oidint2, oidint4, oidname are gone (must be removed from regression tests); use System Cache rather than sequential scan in many places; heap_modifytuple no longer takes buffer parameter; remove unused buffer parameter in a few other functions; oid8 is not index-able; remove some use of single-character variable names; cleanup Buffer variables usage and scan descriptor looping; cleaned up allocation and freeing of tuples; 18k lines of diff;
1998-08-19 04:04:17 +02:00
if (!HeapTupleIsValid(tuple))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "cache lookup failed for relation %u",
RelationGetRelid(rel));
heap_fetch requires buffer pointer, must be released; heap_getnext no longer returns buffer pointer, can be gotten from scan; descriptor; bootstrap can create multi-key indexes; pg_procname index now is multi-key index; oidint2, oidint4, oidname are gone (must be removed from regression tests); use System Cache rather than sequential scan in many places; heap_modifytuple no longer takes buffer parameter; remove unused buffer parameter in a few other functions; oid8 is not index-able; remove some use of single-character variable names; cleanup Buffer variables usage and scan descriptor looping; cleaned up allocation and freeing of tuples; 18k lines of diff;
1998-08-19 04:04:17 +02:00
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
((Form_pg_class) GETSTRUCT(tuple))->relhastriggers = true;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Fix all the places that called heap_update() and heap_delete() without bothering to check the return value --- which meant that in case the update or delete failed because of a concurrent update, you'd not find out about it, except by observing later that the transaction produced the wrong outcome. There are now subroutines simple_heap_update and simple_heap_delete that should be used anyplace that you're not prepared to do the full nine yards of coping with concurrent updates. In practice, that seems to mean absolutely everywhere but the executor, because *noplace* else was checking.
2001-01-23 05:32:23 +01:00
simple_heap_update(pgrel, &tuple->t_self, tuple);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Restructure system-catalog index updating logic. Instead of having hardwired lists of index names for each catalog, use the relcache's mechanism for caching lists of OIDs of indexes of any table. This reduces the common case of updating system catalog indexes to a single line, makes it much easier to add a new system index (in fact, you can now do so on-the-fly if you want to), and as a nice side benefit improves performance a little. Per recent pghackers discussion.
2002-08-05 05:29:17 +02:00
CatalogUpdateIndexes(pgrel, tuple);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Some changes to prepare for LONG attributes. Jan
1999-12-16 23:20:03 +01:00
heap_freetuple(tuple);
Mega-commit to make heap_open/heap_openr/heap_close take an additional argument specifying the kind of lock to acquire/release (or 'NoLock' to do no lock processing). Ensure that all relations are locked with some appropriate lock level before being examined --- this ensures that relevant shared-inval messages have been processed and should prevent problems caused by concurrent VACUUM. Fix several bugs having to do with mismatched increment/decrement of relation ref count and mismatched heap_open/close (which amounts to the same thing). A bogus ref count on a relation doesn't matter much *unless* a SI Inval message happens to arrive at the wrong time, which is probably why we got away with this sloppiness for so long. Repair missing grab of AccessExclusiveLock in DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi. Recommend 'make clean all' after pulling this update; I modified the Relation struct layout slightly. Will post further discussion to pghackers list shortly.
1999-09-18 21:08:25 +02:00
heap_close(pgrel, RowExclusiveLock);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
/*
* We used to try to update the rel's relcache entry here, but that's
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* fairly pointless since it will happen as a byproduct of the upcoming
* CommandCounterIncrement...
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
*/
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Record dependencies for trigger. Always place a normal dependency on
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
* the function.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
myself.classId = TriggerRelationId;
myself.objectId = trigoid;
myself.objectSubId = 0;
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
referenced.classId = ProcedureRelationId;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
referenced.objectId = funcoid;
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (isInternal && OidIsValid(constraintOid))
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
{
/*
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* Internally-generated trigger for a constraint, so make it an
* internal dependency of the constraint. We can skip depending on
* the relation(s), as there'll be an indirect dependency via the
* constraint.
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
*/
referenced.classId = ConstraintRelationId;
referenced.objectId = constraintOid;
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_INTERNAL);
}
else
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* User CREATE TRIGGER, so place dependencies. We make trigger be
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
* auto-dropped if its relation is dropped or if the FK relation is
* dropped. (Auto drop is compatible with our pre-7.3 behavior.)
*/
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
referenced.classId = RelationRelationId;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
referenced.objectId = RelationGetRelid(rel);
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_AUTO);
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
if (OidIsValid(constrrelid))
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
First phase of project to use fixed OIDs for all system catalogs and indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
2005-04-14 03:38:22 +02:00
referenced.classId = RelationRelationId;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
referenced.objectId = constrrelid;
referenced.objectSubId = 0;
recordDependencyOn(&myself, &referenced, DEPENDENCY_AUTO);
}
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
/* Not possible to have an index dependency in this case */
Assert(!OidIsValid(indexOid));
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
/*
* If it's a user-specified constraint trigger, make the constraint
* internally dependent on the trigger instead of vice versa.
*/
if (OidIsValid(constraintOid))
{
referenced.classId = ConstraintRelationId;
referenced.objectId = constraintOid;
referenced.objectSubId = 0;
recordDependencyOn(&referenced, &myself, DEPENDENCY_INTERNAL);
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
}
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
/* If column-specific trigger, add normal dependencies on columns */
if (columns != NULL)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
int i;
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
referenced.classId = RelationRelationId;
referenced.objectId = RelationGetRelid(rel);
for (i = 0; i < ncolumns; i++)
{
referenced.objectSubId = columns[i];
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);
}
}
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* If it has a WHEN clause, add dependencies on objects mentioned in the
* expression (eg, functions, as well as any columns used).
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
*/
if (whenClause != NULL)
recordDependencyOnExpr(&myself, whenClause, whenRtable,
DEPENDENCY_NORMAL);
Mega-commit to make heap_open/heap_openr/heap_close take an additional argument specifying the kind of lock to acquire/release (or 'NoLock' to do no lock processing). Ensure that all relations are locked with some appropriate lock level before being examined --- this ensures that relevant shared-inval messages have been processed and should prevent problems caused by concurrent VACUUM. Fix several bugs having to do with mismatched increment/decrement of relation ref count and mismatched heap_open/close (which amounts to the same thing). A bogus ref count on a relation doesn't matter much *unless* a SI Inval message happens to arrive at the wrong time, which is probably why we got away with this sloppiness for so long. Repair missing grab of AccessExclusiveLock in DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi. Recommend 'make clean all' after pulling this update; I modified the Relation struct layout slightly. Will post further discussion to pghackers list shortly.
1999-09-18 21:08:25 +02:00
/* Keep lock on target rel until end of xact */
heap_close(rel, NoLock);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
return trigoid;
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/*
* Convert legacy (pre-7.3) CREATE CONSTRAINT TRIGGER commands into
* full-fledged foreign key constraints.
*
* The conversion is complex because a pre-7.3 foreign key involved three
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* separate triggers, which were reported separately in dumps. While the
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
* single trigger on the referencing table adds no new information, we need
* to know the trigger functions of both of the triggers on the referenced
* table to build the constraint declaration. Also, due to lack of proper
* dependency checking pre-7.3, it is possible that the source database had
* an incomplete set of triggers resulting in an only partially enforced
* FK constraint. (This would happen if one of the tables had been dropped
* and re-created, but only if the DB had been affected by a 7.0 pg_dump bug
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* that caused loss of tgconstrrelid information.) We choose to translate to
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
* an FK constraint only when we've seen all three triggers of a set. This is
* implemented by storing unmatched items in a list in TopMemoryContext.
* We match triggers together by comparing the trigger arguments (which
* include constraint name, table and column names, so should be good enough).
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
*/
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
typedef struct
{
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
List *args; /* list of (T_String) Values or NIL */
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
Oid funcoids[3]; /* OIDs of trigger functions */
/* The three function OIDs are stored in the order update, delete, child */
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
} OldTriggerInfo;
static void
ConvertTriggerToFK(CreateTrigStmt *stmt, Oid funcoid)
{
static List *info_list = NIL;
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
static const char *const funcdescr[3] = {
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
gettext_noop("Found referenced table's UPDATE trigger."),
gettext_noop("Found referenced table's DELETE trigger."),
gettext_noop("Found referencing table's trigger.")
};
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
char *constr_name;
char *fk_table_name;
char *pk_table_name;
char fk_matchtype = FKCONSTR_MATCH_UNSPECIFIED;
List *fk_attrs = NIL;
List *pk_attrs = NIL;
StringInfoData buf;
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
int funcnum;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
OldTriggerInfo *info = NULL;
ListCell *l;
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
int i;
/* Parse out the trigger arguments */
constr_name = strVal(linitial(stmt->args));
fk_table_name = strVal(lsecond(stmt->args));
pk_table_name = strVal(lthird(stmt->args));
i = 0;
foreach(l, stmt->args)
{
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
Value *arg = (Value *) lfirst(l);
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
i++;
if (i < 4) /* skip constraint and table names */
continue;
if (i == 4) /* handle match type */
{
if (strcmp(strVal(arg), "FULL") == 0)
fk_matchtype = FKCONSTR_MATCH_FULL;
else
fk_matchtype = FKCONSTR_MATCH_UNSPECIFIED;
continue;
}
if (i % 2)
fk_attrs = lappend(fk_attrs, arg);
else
pk_attrs = lappend(pk_attrs, arg);
}
/* Prepare description of constraint for use in messages */
initStringInfo(&buf);
appendStringInfo(&buf, "FOREIGN KEY %s(",
quote_identifier(fk_table_name));
i = 0;
foreach(l, fk_attrs)
{
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
Value *arg = (Value *) lfirst(l);
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
if (i++ > 0)
appendStringInfoChar(&buf, ',');
appendStringInfoString(&buf, quote_identifier(strVal(arg)));
}
appendStringInfo(&buf, ") REFERENCES %s(",
quote_identifier(pk_table_name));
i = 0;
foreach(l, pk_attrs)
{
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
Value *arg = (Value *) lfirst(l);
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
if (i++ > 0)
appendStringInfoChar(&buf, ',');
appendStringInfoString(&buf, quote_identifier(strVal(arg)));
}
appendStringInfoChar(&buf, ')');
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/* Identify class of trigger --- update, delete, or referencing-table */
switch (funcoid)
{
case F_RI_FKEY_CASCADE_UPD:
case F_RI_FKEY_RESTRICT_UPD:
case F_RI_FKEY_SETNULL_UPD:
case F_RI_FKEY_SETDEFAULT_UPD:
case F_RI_FKEY_NOACTION_UPD:
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
funcnum = 0;
break;
case F_RI_FKEY_CASCADE_DEL:
case F_RI_FKEY_RESTRICT_DEL:
case F_RI_FKEY_SETNULL_DEL:
case F_RI_FKEY_SETDEFAULT_DEL:
case F_RI_FKEY_NOACTION_DEL:
funcnum = 1;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
break;
default:
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
funcnum = 2;
break;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
}
/* See if we have a match to this trigger */
foreach(l, info_list)
{
info = (OldTriggerInfo *) lfirst(l);
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
if (info->funcoids[funcnum] == InvalidOid &&
equal(info->args, stmt->args))
{
info->funcoids[funcnum] = funcoid;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
break;
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
}
if (l == NULL)
{
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
/* First trigger of set, so create a new list entry */
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
MemoryContext oldContext;
ereport(NOTICE,
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
(errmsg("ignoring incomplete trigger group for constraint \"%s\" %s",
constr_name, buf.data),
Make some strings translatable again that were accidentally removed in earlier patch to fix "printf-arguments".
2009-01-21 10:28:26 +01:00
errdetail("%s", _(funcdescr[funcnum]))));
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
oldContext = MemoryContextSwitchTo(TopMemoryContext);
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
info = (OldTriggerInfo *) palloc0(sizeof(OldTriggerInfo));
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
info->args = copyObject(stmt->args);
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
info->funcoids[funcnum] = funcoid;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
info_list = lappend(info_list, info);
MemoryContextSwitchTo(oldContext);
}
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
else if (info->funcoids[0] == InvalidOid ||
info->funcoids[1] == InvalidOid ||
info->funcoids[2] == InvalidOid)
{
/* Second trigger of set */
ereport(NOTICE,
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
(errmsg("ignoring incomplete trigger group for constraint \"%s\" %s",
constr_name, buf.data),
Make some strings translatable again that were accidentally removed in earlier patch to fix "printf-arguments".
2009-01-21 10:28:26 +01:00
errdetail("%s", _(funcdescr[funcnum]))));
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
else
{
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
/* OK, we have a set, so make the FK constraint ALTER TABLE cmd */
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
AlterTableStmt *atstmt = makeNode(AlterTableStmt);
AlterTableCmd *atcmd = makeNode(AlterTableCmd);
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
Constraint *fkcon = makeNode(Constraint);
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
ereport(NOTICE,
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
(errmsg("converting trigger group into constraint \"%s\" %s",
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
constr_name, buf.data),
Make some strings translatable again that were accidentally removed in earlier patch to fix "printf-arguments".
2009-01-21 10:28:26 +01:00
errdetail("%s", _(funcdescr[funcnum]))));
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
fkcon->contype = CONSTR_FOREIGN;
fkcon->location = -1;
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
if (funcnum == 2)
{
/* This trigger is on the FK table */
atstmt->relation = stmt->relation;
if (stmt->constrrel)
fkcon->pktable = stmt->constrrel;
else
{
/* Work around ancient pg_dump bug that omitted constrrel */
Add a bunch of new error location reports to parse-analysis error messages. There are still some weak spots around JOIN USING and relation alias lists, but most errors reported within backend/parser/ now have locations.
2008-09-01 22:42:46 +02:00
fkcon->pktable = makeRangeVar(NULL, pk_table_name, -1);
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
}
}
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
else
{
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
/* This trigger is on the PK table */
fkcon->pktable = stmt->relation;
if (stmt->constrrel)
atstmt->relation = stmt->constrrel;
else
{
/* Work around ancient pg_dump bug that omitted constrrel */
Add a bunch of new error location reports to parse-analysis error messages. There are still some weak spots around JOIN USING and relation alias lists, but most errors reported within backend/parser/ now have locations.
2008-09-01 22:42:46 +02:00
atstmt->relation = makeRangeVar(NULL, fk_table_name, -1);
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
}
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
}
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
atstmt->cmds = list_make1(atcmd);
atstmt->relkind = OBJECT_TABLE;
atcmd->subtype = AT_AddConstraint;
atcmd->def = (Node *) fkcon;
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
if (strcmp(constr_name, "<unnamed>") == 0)
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
fkcon->conname = NULL;
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
else
Merge the Constraint and FkConstraint node types into a single type. This was foreseen to be a good idea long ago, but nobody had got round to doing it. The recent patch for deferred unique constraints made transformConstraintAttrs() ugly enough that I decided it was time. This change will also greatly simplify parsing of deferred CHECK constraints, if anyone ever gets around to implementing that. While at it, add a location field to Constraint, and use that to provide an error cursor for some of the constraint-related error messages.
2009-07-30 04:45:38 +02:00
fkcon->conname = constr_name;
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
fkcon->fk_attrs = fk_attrs;
fkcon->pk_attrs = pk_attrs;
fkcon->fk_matchtype = fk_matchtype;
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
switch (info->funcoids[0])
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
{
case F_RI_FKEY_NOACTION_UPD:
fkcon->fk_upd_action = FKCONSTR_ACTION_NOACTION;
break;
case F_RI_FKEY_CASCADE_UPD:
fkcon->fk_upd_action = FKCONSTR_ACTION_CASCADE;
break;
case F_RI_FKEY_RESTRICT_UPD:
fkcon->fk_upd_action = FKCONSTR_ACTION_RESTRICT;
break;
case F_RI_FKEY_SETNULL_UPD:
fkcon->fk_upd_action = FKCONSTR_ACTION_SETNULL;
break;
case F_RI_FKEY_SETDEFAULT_UPD:
fkcon->fk_upd_action = FKCONSTR_ACTION_SETDEFAULT;
break;
default:
/* can't get here because of earlier checks */
elog(ERROR, "confused about RI update function");
}
Improve conversion of legacy CREATE CONSTRAINT TRIGGER representation of foreign keys, one more time. Insist on matching up all three triggers before we create a constraint; this will avoid creation of duplicate constraints in scenarios where a broken FK constraint was repaired by re-adding the constraint without removing the old partial trigger set. Basically, this will work nicely in all cases where the FK was actually functioning correctly in the database that was dumped. It will fail to restore an FK in just one case where we theoretically could restore it: where we find the referenced table's triggers and not the referencing table's trigger. However, in such a scenario it's likely that the user doesn't even realize he still has an FK at all (since the more-likely-to-fail cases aren't enforced), and we'd probably not accomplish much except to cause the reload to fail because the data doesn't meet the FK constraint. Also make the NOTICE logging still more verbose, by adding detail about which of the triggers were found. This seems about all we can do without solving the problem of getting the user's attention at session end.
2007-11-05 20:00:25 +01:00
switch (info->funcoids[1])
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
{
case F_RI_FKEY_NOACTION_DEL:
fkcon->fk_del_action = FKCONSTR_ACTION_NOACTION;
break;
case F_RI_FKEY_CASCADE_DEL:
fkcon->fk_del_action = FKCONSTR_ACTION_CASCADE;
break;
case F_RI_FKEY_RESTRICT_DEL:
fkcon->fk_del_action = FKCONSTR_ACTION_RESTRICT;
break;
case F_RI_FKEY_SETNULL_DEL:
fkcon->fk_del_action = FKCONSTR_ACTION_SETNULL;
break;
case F_RI_FKEY_SETDEFAULT_DEL:
fkcon->fk_del_action = FKCONSTR_ACTION_SETDEFAULT;
break;
default:
/* can't get here because of earlier checks */
elog(ERROR, "confused about RI delete function");
}
fkcon->deferrable = stmt->deferrable;
fkcon->initdeferred = stmt->initdeferred;
Minor improvements to code for converting legacy CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints. Believe the constraint name given in the trigger arguments in preference to the trigger name --- to judge from Olivier Prenant's example, pg_dump must at some time have used the autogenerated trigger name there, though AFAICT no current release branch tip does. Improve the emitted NOTICEs to provide more detail (PK table's name and column names). Handle the case where pg_dump forgot to provide the FROM table (a bug that never did get fixed in 7.0.x apparently). This commit doesn't do anything about the question of what to do with incomplete trigger groups.
2007-11-04 22:25:55 +01:00
/* ... and execute it */
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
ProcessUtility((Node *) atstmt,
Adjust things so that the query_string of a cached plan and the sourceText of a portal are never NULL, but reliably provide the source text of the query. It turns out that there was only one place that was really taking a short-cut, which was the 'EXECUTE' utility statement. That doesn't seem like a sufficiently critical performance hotspot to justify not offering a guarantee of validity of the portal source text. Fix it to copy the source text over from the cached plan. Add Asserts in the places that set up cached plans and portals to reject null source strings, and simplify a bunch of places that formerly needed to guard against nulls. There may be a few places that cons up statements for execution without having any source text at all; I found one such in ConvertTriggerToFK(). It seems sufficient to inject a phony source string in such a case, for instance ProcessUtility((Node *) atstmt, "(generated ALTER TABLE ADD FOREIGN KEY command)", NULL, false, None_Receiver, NULL); We should take a second look at the usage of debug_query_string, particularly the recently added current_query() SQL function. ITAGAKI Takahiro and Tom Lane
2008-07-18 22:26:06 +02:00
"(generated ALTER TABLE ADD FOREIGN KEY command)",
NULL, false, None_Receiver, NULL);
Teach CREATE CONSTRAINT TRIGGER to convert old-style foreign key trigger definitions into regular foreign key constraints. This seems necessary given that some people evidently never did get around to running adddepend on their schemas, and without some sort of hack the old definitions will no longer work. Per report from Olivier Prenant and subsequent investigation.
2007-11-04 02:16:19 +01:00
/* Remove the matched item from the list */
info_list = list_delete_ptr(info_list, info);
pfree(info);
/* We leak the copied args ... not worth worrying about */
}
}
Mop-up some infelicities in new relation lookup handling.
2002-03-29 23:10:34 +01:00
/*
* DropTrigger - drop an individual trigger by name
*/
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
void
DROP ... IF EXISTS for the following cases: language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.
2006-06-16 22:23:45 +02:00
DropTrigger(Oid relid, const char *trigname, DropBehavior behavior,
bool missing_ok)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
{
pgindent run.
2002-09-04 22:31:48 +02:00
Relation tgrel;
ScanKeyData skey[2];
SysScanDesc tgscan;
HeapTuple tup;
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
ObjectAddress object;
/*
* Find the trigger, verify permissions, set up object address
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgrel = heap_open(TriggerRelationId, AccessShareLock);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&skey[0],
Anum_pg_trigger_tgrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(relid));
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&skey[1],
Anum_pg_trigger_tgname,
BTEqualStrategyNumber, F_NAMEEQ,
CStringGetDatum(trigname));
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
SnapshotNow, 2, skey);
tup = systable_getnext(tgscan);
if (!HeapTupleIsValid(tup))
DROP ... IF EXISTS for the following cases: language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.
2006-06-16 22:23:45 +02:00
{
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
if (!missing_ok)
DROP ... IF EXISTS for the following cases: language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.
2006-06-16 22:23:45 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("trigger \"%s\" for table \"%s\" does not exist",
trigname, get_rel_name(relid))));
else
ereport(NOTICE,
Make some sentences consistent with similar ones. Euler Taveira de Oliveira
2006-10-03 23:21:36 +02:00
(errmsg("trigger \"%s\" for table \"%s\" does not exist, skipping",
DROP ... IF EXISTS for the following cases: language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.
2006-06-16 22:23:45 +02:00
trigname, get_rel_name(relid))));
/* cleanup */
systable_endscan(tgscan);
heap_close(tgrel, AccessShareLock);
return;
}
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
if (!pg_class_ownercheck(relid, GetUserId()))
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_CLASS,
get_rel_name(relid));
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
object.classId = TriggerRelationId;
oid is needed, it is added at the end of the struct (after the null bitmap, if present). Per Tom Lane's suggestion the information whether a tuple has an oid or not is carried in the tuple descriptor. For debugging reasons tdhasoid is of type char, not bool. There are predefined values for WITHOID, WITHOUTOID and UNDEFOID. This patch has been generated against a cvs snapshot from last week and I don't expect it to apply cleanly to current sources. While I post it here for public review, I'm working on a new version against a current snapshot. (There's been heavy activity recently; hope to catch up some day ...) This is a long patch; if it is too hard to swallow, I can provide it in smaller pieces: Part 1: Accessor macros Part 2: tdhasoid in TupDesc Part 3: Regression test Part 4: Parameter withoid to heap_addheader Part 5: Eliminate t_oid from HeapTupleHeader Part 2 is the most hairy part because of changes in the executor and even in the parser; the other parts are straightforward. Up to part 4 the patched postmaster stays binary compatible to databases created with an unpatched version. Part 5 is small (100 lines) and finally breaks compatibility. Manfred Koizar
2002-07-20 07:16:59 +02:00
object.objectId = HeapTupleGetOid(tup);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
object.objectSubId = 0;
systable_endscan(tgscan);
heap_close(tgrel, AccessShareLock);
/*
* Do the deletion
*/
performDeletion(&object, behavior);
}
/*
* Guts of trigger deletion.
*/
void
RemoveTriggerById(Oid trigOid)
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
{
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
Relation tgrel;
pgindent run.
2002-09-04 22:31:48 +02:00
SysScanDesc tgscan;
ScanKeyData skey[1];
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
HeapTuple tup;
Oid relid;
Relation rel;
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgrel = heap_open(TriggerRelationId, RowExclusiveLock);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
* Find the trigger to delete.
*/
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&skey[0],
ObjectIdAttributeNumber,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(trigOid));
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgscan = systable_beginscan(tgrel, TriggerOidIndexId, true,
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
SnapshotNow, 1, skey);
tup = systable_getnext(tgscan);
if (!HeapTupleIsValid(tup))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "could not find tuple for trigger %u", trigOid);
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/*
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
* Open and lock the relation the trigger belongs to. As in
* CreateTrigger, this is sufficient to lock out all operations that
* could fire or add triggers; but it would need to be revisited if
* we had ON SELECT triggers.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
*/
relid = ((Form_pg_trigger) GETSTRUCT(tup))->tgrelid;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. Avoid hard-coding lockmode used for many altering DDL commands, allowing easier future changes of lock levels. Implementation of initial analysis on DDL sub-commands, so that many lock levels are now at ShareUpdateExclusiveLock or ShareRowExclusiveLock, allowing certain DDL not to block reads/writes. First of number of planned changes in this area; additional docs required when full project complete.
2010-07-28 07:22:24 +02:00
rel = heap_open(relid, ShareRowExclusiveLock);
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
if (rel->rd_rel->relkind != RELKIND_RELATION)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is not a table",
RelationGetRelationName(rel))));
Change the aclchk.c routines to uniformly use OIDs to identify the objects to be privilege-checked. Some change in their APIs would be necessary no matter what in the schema environment, and simply getting rid of the name-based interface entirely seems like the best way.
2002-03-22 00:27:25 +01:00
Checking to decide whether relations are system relations now depends on the namespace not the name; pg_ is not a reserved prefix for table names anymore. From Fernando Nasser.
2002-04-12 22:38:31 +02:00
if (!allowSystemTableMods && IsSystemRelation(rel))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
Adjust 'permission denied' messages to be more useful and consistent.
2003-08-01 02:15:26 +02:00
errmsg("permission denied: \"%s\" is a system catalog",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
RelationGetRelationName(rel))));
Require ownership permission for CREATE INDEX, per bug report. Disallow CREATE INDEX on system catalogs, non-tables (views, sequences, etc). Disallow CREATE/DROP TRIGGER on system catalogs, non-tables. Disallow ALTER TABLE ADD/DROP CONSTRAINT on system catalogs. Disallow FOREIGN KEY reference to non-table. None of these things can actually work in the present system structure, but the code was letting them pass without complaint.
2002-01-04 00:21:32 +01:00
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
/*
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
* Delete the pg_trigger tuple.
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
*/
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
simple_heap_delete(tgrel, &tup->t_self);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
systable_endscan(tgscan);
heap_close(tgrel, RowExclusiveLock);
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
/*
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
* We do not bother to try to determine whether any other triggers remain,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* which would be needed in order to decide whether it's safe to clear the
* relation's relhastriggers. (In any case, there might be a concurrent
* process adding new triggers.) Instead, just force a relcache inval to
* make other backends (and this one too!) rebuild their relcache entries.
* There's no great harm in leaving relhastriggers true even if there are
* no triggers left.
Clean up memory-context stuff, other minor infelicities.
2000-07-03 05:57:03 +02:00
*/
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
CacheInvalidateRelcache(rel);
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
/* Keep lock on trigger's rel until end of xact */
Mega-commit to make heap_open/heap_openr/heap_close take an additional argument specifying the kind of lock to acquire/release (or 'NoLock' to do no lock processing). Ensure that all relations are locked with some appropriate lock level before being examined --- this ensures that relevant shared-inval messages have been processed and should prevent problems caused by concurrent VACUUM. Fix several bugs having to do with mismatched increment/decrement of relation ref count and mismatched heap_open/close (which amounts to the same thing). A bogus ref count on a relation doesn't matter much *unless* a SI Inval message happens to arrive at the wrong time, which is probably why we got away with this sloppiness for so long. Repair missing grab of AccessExclusiveLock in DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi. Recommend 'make clean all' after pulling this update; I modified the Relation struct layout slightly. Will post further discussion to pghackers list shortly.
1999-09-18 21:08:25 +02:00
heap_close(rel, NoLock);
Workplace for CREATE/DROP TRIGGER
1997-08-31 13:40:13 +02:00
}
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* renametrig - changes the name of a trigger on a relation
*
* trigger name is changed in trigger catalog.
* No record of the previous name is kept.
*
* get proper relrelation from relation catalog (if not arg)
* scan trigger catalog
* for name conflict (within rel)
* for original trigger (if not arg)
* modify tgname in trigger tuple
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
* update row in catalog
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
void
renametrig(Oid relid,
const char *oldname,
const char *newname)
{
Relation targetrel;
Relation tgrel;
HeapTuple tuple;
pgindent run.
2002-09-04 22:31:48 +02:00
SysScanDesc tgscan;
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
ScanKeyData key[2];
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Grab an exclusive lock on the target table, which we will NOT release
* until end of transaction.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*/
targetrel = heap_open(relid, AccessExclusiveLock);
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Scan pg_trigger twice for existing triggers on relation. We do this in
* order to ensure a trigger does not exist with newname (The unique index
* on tgrelid/tgname would complain anyway) and to ensure a trigger does
* exist with oldname.
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
*
* NOTE that this is cool only because we have AccessExclusiveLock on the
* relation, so the trigger set won't be changing underneath us.
*/
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgrel = heap_open(TriggerRelationId, RowExclusiveLock);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* First pass -- look for name conflict
*/
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&key[0],
Anum_pg_trigger_tgrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(relid));
ScanKeyInit(&key[1],
Anum_pg_trigger_tgname,
BTEqualStrategyNumber, F_NAMEEQ,
PointerGetDatum(newname));
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
SnapshotNow, 2, key);
if (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("trigger \"%s\" for relation \"%s\" already exists",
newname, RelationGetRelationName(targetrel))));
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
systable_endscan(tgscan);
/*
* Second pass -- look for trigger existing with oldname and update
*/
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&key[0],
Anum_pg_trigger_tgrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(relid));
ScanKeyInit(&key[1],
Anum_pg_trigger_tgname,
BTEqualStrategyNumber, F_NAMEEQ,
PointerGetDatum(oldname));
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
SnapshotNow, 2, key);
if (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
{
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
/*
* Update pg_trigger tuple with new tgname.
*/
pgindent run.
2002-09-04 22:31:48 +02:00
tuple = heap_copytuple(tuple); /* need a modifiable copy */
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
namestrcpy(&((Form_pg_trigger) GETSTRUCT(tuple))->tgname, newname);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
simple_heap_update(tgrel, &tuple->t_self, tuple);
Restructure system-catalog index updating logic. Instead of having hardwired lists of index names for each catalog, use the relcache's mechanism for caching lists of OIDs of indexes of any table. This reduces the common case of updating system catalog indexes to a single line, makes it much easier to add a new system index (in fact, you can now do so on-the-fly if you want to), and as a nice side benefit improves performance a little. Per recent pghackers discussion.
2002-08-05 05:29:17 +02:00
/* keep system catalog indexes current */
CatalogUpdateIndexes(tgrel, tuple);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Invalidate relation's relcache entry so that other backends (and
* this one too!) are sent SI message to make them rebuild relcache
* entries. (Ideally this should happen automatically...)
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
*/
Restructure smgr API as per recent proposal. smgr no longer depends on the relcache, and so the notion of 'blind write' is gone. This should improve efficiency in bgwriter and background checkpoint processes. Internal restructuring in md.c to remove the not-very-useful array of MdfdVec objects --- might as well just use pointers. Also remove the long-dead 'persistent main memory' storage manager (mm.c), since it seems quite unlikely to ever get resurrected.
2004-02-10 02:55:27 +01:00
CacheInvalidateRelcache(targetrel);
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
}
else
{
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("trigger \"%s\" for table \"%s\" does not exist",
oldname, RelationGetRelationName(targetrel))));
Code review for ALTER TRIGGER RENAME patch: make better use of index, don't scribble on tuple returned by table scan.
2002-04-30 03:24:57 +02:00
}
systable_endscan(tgscan);
heap_close(tgrel, RowExclusiveLock);
Move renametrig() from tablecmds.c to trigger.c --- if we're going to divide backend/commands by object type, let's try to pay at least minimal attention to respecting that structure, eh? Also reorder the contents of tablecmds.c; it seems odd to me to put ALTER commands before creation/deletion commands.
2002-04-26 21:29:47 +02:00
/*
* Close rel, but keep exclusive lock!
*/
heap_close(targetrel, NoLock);
}
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
/*
* EnableDisableTrigger()
*
Update comments to reflect that tgenabled is not a boolean anymore. Jonah Harris, with minor tinkering by me.
2009-01-22 20:16:31 +01:00
* Called by ALTER TABLE ENABLE/DISABLE [ REPLICA | ALWAYS ] TRIGGER
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
* to change 'tgenabled' field for the specified trigger(s)
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
*
* rel: relation to process (caller must hold suitable lock on it)
* tgname: trigger to process, or NULL to scan all triggers
Update comments to reflect that tgenabled is not a boolean anymore. Jonah Harris, with minor tinkering by me.
2009-01-22 20:16:31 +01:00
* fires_when: new value for tgenabled field. In addition to generic
* enablement/disablement, this also defines when the trigger
* should be fired in session replication roles.
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
* skip_system: if true, skip "system" triggers (constraint triggers)
*
* Caller should have checked permissions for the table; here we also
* enforce that superuser privilege is required to alter the state of
* system triggers
*/
void
EnableDisableTrigger(Relation rel, const char *tgname,
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
char fires_when, bool skip_system)
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Relation tgrel;
int nkeys;
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
ScanKeyData keys[2];
SysScanDesc tgscan;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
HeapTuple tuple;
bool found;
bool changed;
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
/* Scan the relevant entries in pg_triggers */
tgrel = heap_open(TriggerRelationId, RowExclusiveLock);
ScanKeyInit(&keys[0],
Anum_pg_trigger_tgrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(rel)));
if (tgname)
{
ScanKeyInit(&keys[1],
Anum_pg_trigger_tgname,
BTEqualStrategyNumber, F_NAMEEQ,
CStringGetDatum(tgname));
nkeys = 2;
}
else
nkeys = 1;
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
SnapshotNow, nkeys, keys);
found = changed = false;
while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
{
Form_pg_trigger oldtrig = (Form_pg_trigger) GETSTRUCT(tuple);
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (oldtrig->tgisinternal)
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
{
/* system trigger ... ok to process? */
if (skip_system)
continue;
if (!superuser())
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("permission denied: \"%s\" is a system trigger",
NameStr(oldtrig->tgname))));
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
}
found = true;
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
if (oldtrig->tgenabled != fires_when)
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
{
/* need to change this one ... make a copy to scribble on */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
HeapTuple newtup = heap_copytuple(tuple);
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
Form_pg_trigger newtrig = (Form_pg_trigger) GETSTRUCT(newtup);
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
newtrig->tgenabled = fires_when;
Add ALTER TABLE ENABLE/DISABLE TRIGGER commands. Change pg_dump to use these instead of its previous hack of changing pg_class.reltriggers. Documentation is lacking, will add that later. Patch by Satoshi Nagayasu, review and some extra work by Tom Lane.
2005-08-24 00:40:47 +02:00
simple_heap_update(tgrel, &newtup->t_self, newtup);
/* Keep catalog indexes current */
CatalogUpdateIndexes(tgrel, newtup);
heap_freetuple(newtup);
changed = true;
}
}
systable_endscan(tgscan);
heap_close(tgrel, RowExclusiveLock);
if (tgname && !found)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("trigger \"%s\" for table \"%s\" does not exist",
tgname, RelationGetRelationName(rel))));
/*
* If we changed anything, broadcast a SI inval message to force each
* backend (including our own!) to rebuild relation's relcache entry.
* Otherwise they will fail to apply the change promptly.
*/
if (changed)
CacheInvalidateRelcache(rel);
}
Use a private memory context to store rule information in each relcache entry that has rules. This allows us to release the rule parsetrees on relcache flush without needing a working freeObject() routine. Formerly, the rule trees were leaked permanently at relcache flush. Also, clean up handling of rule creation and deletion --- there was not sufficient locking of the relation being modified, and there was no reliable notification of other backends that a relcache reload was needed. Also, clean up relcache.c code so that scans of system tables needed to load a relcache entry are done in the caller's memory context, not in CacheMemoryContext. This prevents any un-pfreed memory from those scans from becoming a permanent memory leak.
2000-06-30 09:04:23 +02:00
/*
* Build trigger data to attach to the given relcache entry.
*
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
* Note that trigger data attached to a relcache entry must be stored in
* CacheMemoryContext to ensure it survives as long as the relcache entry.
* But we should be running in a less long-lived working context. To avoid
* leaking cache memory if this routine fails partway through, we build a
* temporary TriggerDesc in working memory and then copy the completed
* structure into cache memory.
Use a private memory context to store rule information in each relcache entry that has rules. This allows us to release the rule parsetrees on relcache flush without needing a working freeObject() routine. Formerly, the rule trees were leaked permanently at relcache flush. Also, clean up handling of rule creation and deletion --- there was not sufficient locking of the relation being modified, and there was no reliable notification of other backends that a relcache reload was needed. Also, clean up relcache.c code so that scans of system tables needed to load a relcache entry are done in the caller's memory context, not in CacheMemoryContext. This prevents any un-pfreed memory from those scans from becoming a permanent memory leak.
2000-06-30 09:04:23 +02:00
*/
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
void
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
RelationBuildTriggers(Relation relation)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Use a private memory context to store rule information in each relcache entry that has rules. This allows us to release the rule parsetrees on relcache flush without needing a working freeObject() routine. Formerly, the rule trees were leaked permanently at relcache flush. Also, clean up handling of rule creation and deletion --- there was not sufficient locking of the relation being modified, and there was no reliable notification of other backends that a relcache reload was needed. Also, clean up relcache.c code so that scans of system tables needed to load a relcache entry are done in the caller's memory context, not in CacheMemoryContext. This prevents any un-pfreed memory from those scans from becoming a permanent memory leak.
2000-06-30 09:04:23 +02:00
TriggerDesc *trigdesc;
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
int numtrigs;
int maxtrigs;
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.
2002-04-19 18:36:08 +02:00
Trigger *triggers;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
Relation tgrel;
ScanKeyData skey;
pgindent run.
2002-09-04 22:31:48 +02:00
SysScanDesc tgscan;
Implement reindex command
2000-02-18 10:30:20 +01:00
HeapTuple htup;
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
MemoryContext oldContext;
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
int i;
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Allocate a working array to hold the triggers (the array is extended if
* necessary)
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
*/
maxtrigs = 16;
triggers = (Trigger *) palloc(maxtrigs * sizeof(Trigger));
numtrigs = 0;
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.
2002-04-19 18:36:08 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Note: since we scan the triggers using TriggerRelidNameIndexId, we will
* be reading the triggers in name order, except possibly during
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* emergency-recovery operations (ie, IgnoreSystemIndexes). This in turn
* ensures that triggers will be fired in name order.
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.
2002-04-19 18:36:08 +02:00
*/
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
ScanKeyInit(&skey,
Anum_pg_trigger_tgrelid,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(RelationGetRelid(relation)));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Completion of project to use fixed OIDs for all system catalogs and indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
2005-04-14 22:03:27 +02:00
tgrel = heap_open(TriggerRelationId, AccessShareLock);
tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
SnapshotNow, 1, &skey);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
while (HeapTupleIsValid(htup = systable_getnext(tgscan)))
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
Form_pg_trigger pg_trigger = (Form_pg_trigger) GETSTRUCT(htup);
Trigger *build;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
Datum datum;
bool isnull;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
if (numtrigs >= maxtrigs)
{
maxtrigs *= 2;
triggers = (Trigger *) repalloc(triggers, maxtrigs * sizeof(Trigger));
}
build = &(triggers[numtrigs]);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
oid is needed, it is added at the end of the struct (after the null bitmap, if present). Per Tom Lane's suggestion the information whether a tuple has an oid or not is carried in the tuple descriptor. For debugging reasons tdhasoid is of type char, not bool. There are predefined values for WITHOID, WITHOUTOID and UNDEFOID. This patch has been generated against a cvs snapshot from last week and I don't expect it to apply cleanly to current sources. While I post it here for public review, I'm working on a new version against a current snapshot. (There's been heavy activity recently; hope to catch up some day ...) This is a long patch; if it is too hard to swallow, I can provide it in smaller pieces: Part 1: Accessor macros Part 2: tdhasoid in TupDesc Part 3: Regression test Part 4: Parameter withoid to heap_addheader Part 5: Eliminate t_oid from HeapTupleHeader Part 2 is the most hairy part because of changes in the executor and even in the parser; the other parts are straightforward. Up to part 4 the patched postmaster stays binary compatible to databases created with an unpatched version. Part 5 is small (100 lines) and finally breaks compatibility. Manfred Koizar
2002-07-20 07:16:59 +02:00
build->tgoid = HeapTupleGetOid(htup);
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
build->tgname = DatumGetCString(DirectFunctionCall1(nameout,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
NameGetDatum(&pg_trigger->tgname)));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
build->tgfoid = pg_trigger->tgfoid;
build->tgtype = pg_trigger->tgtype;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
build->tgenabled = pg_trigger->tgenabled;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
build->tgisinternal = pg_trigger->tgisinternal;
Add tgconstrrelid to stored Trigger structures, make RI trigger functions depend on this rather than the trigger argument strings to locate the other relation to test. This makes RI triggers function properly in the presence of schemas and temp tables. Along the way, fix bogus lack of locking in RI triggers, handle quoting of names fully correctly, compute required sizes of query buffers with some semblance of accuracy.
2002-04-02 00:36:13 +02:00
build->tgconstrrelid = pg_trigger->tgconstrrelid;
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
build->tgconstrindid = pg_trigger->tgconstrindid;
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
build->tgconstraint = pg_trigger->tgconstraint;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
build->tgdeferrable = pg_trigger->tgdeferrable;
build->tginitdeferred = pg_trigger->tginitdeferred;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
build->tgnargs = pg_trigger->tgnargs;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
/* tgattr is first var-width field, so OK to access directly */
build->tgnattr = pg_trigger->tgattr.dim1;
if (build->tgnattr > 0)
{
build->tgattr = (int2 *) palloc(build->tgnattr * sizeof(int2));
memcpy(build->tgattr, &(pg_trigger->tgattr.values),
build->tgnattr * sizeof(int2));
}
else
build->tgattr = NULL;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
if (build->tgnargs > 0)
{
Clean up comments to be careful about the distinction between variable- width types and varlena types, since with the introduction of CSTRING as a more-or-less-real type, these concepts aren't identical. I've tried to use varlena consistently to denote datatypes with typlen = -1, ie, they have a length word and are potentially TOASTable; while the term variable width covers both varlena and cstring (and, perhaps, someday other types with other rules for computing the actual width). No code changes in this commit except for renaming a couple macros.
2002-08-25 19:20:01 +02:00
bytea *val;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
char *p;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Properly detoast access to bytea field pg_trigger.tgargs. Old code might cause server crash. Backpatch to 8.2.X.
2007-01-25 05:17:46 +01:00
val = DatumGetByteaP(fastgetattr(htup,
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
Anum_pg_trigger_tgargs,
tgrel->rd_att, &isnull));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
if (isnull)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
elog(ERROR, "tgargs is null in trigger for relation \"%s\"",
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
RelationGetRelationName(relation));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
p = (char *) VARDATA(val);
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
build->tgargs = (char **) palloc(build->tgnargs * sizeof(char *));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
for (i = 0; i < build->tgnargs; i++)
{
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
build->tgargs[i] = pstrdup(p);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
p += strlen(p) + 1;
}
}
else
build->tgargs = NULL;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
datum = fastgetattr(htup, Anum_pg_trigger_tgqual,
tgrel->rd_att, &isnull);
if (!isnull)
build->tgqual = TextDatumGetCString(datum);
else
build->tgqual = NULL;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
numtrigs++;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
systable_endscan(tgscan);
heap_close(tgrel, AccessShareLock);
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
/* There might not be any triggers */
if (numtrigs == 0)
{
pfree(triggers);
return;
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
/* Build trigdesc */
Add new palloc0 call as merge of palloc and MemSet(0).
2002-11-13 01:39:48 +01:00
trigdesc = (TriggerDesc *) palloc0(sizeof(TriggerDesc));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
trigdesc->triggers = triggers;
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
trigdesc->numtriggers = numtrigs;
for (i = 0; i < numtrigs; i++)
InsertTrigger(trigdesc, &(triggers[i]), i);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
/* Copy completed trigdesc into cache storage */
oldContext = MemoryContextSwitchTo(CacheMemoryContext);
relation->trigdesc = CopyTriggerDesc(trigdesc);
MemoryContextSwitchTo(oldContext);
/* Release working memory */
FreeTriggerDesc(trigdesc);
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
}
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
/*
* Insert the given trigger into the appropriate index list(s) for it
*
* To simplify storage management, we allocate each index list at the max
* possible size (trigdesc->numtriggers) if it's used at all. This does
* not waste space permanently since we're only building a temporary
* trigdesc at this point.
*/
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
static void
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
InsertTrigger(TriggerDesc *trigdesc, Trigger *trigger, int indx)
Before row insertion triggers call.
1997-09-04 15:19:01 +02:00
{
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
uint16 *n;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
int **t,
**tp;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
if (TRIGGER_FOR_ROW(trigger->tgtype))
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
/* ROW trigger */
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
if (TRIGGER_FOR_BEFORE(trigger->tgtype))
{
n = trigdesc->n_before_row;
t = trigdesc->tg_before_row;
}
else
{
n = trigdesc->n_after_row;
t = trigdesc->tg_after_row;
}
}
else
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
/* STATEMENT trigger */
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
if (TRIGGER_FOR_BEFORE(trigger->tgtype))
{
n = trigdesc->n_before_statement;
t = trigdesc->tg_before_statement;
}
else
{
n = trigdesc->n_after_statement;
t = trigdesc->tg_after_statement;
}
}
if (TRIGGER_FOR_INSERT(trigger->tgtype))
{
tp = &(t[TRIGGER_EVENT_INSERT]);
if (*tp == NULL)
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
*tp = (int *) palloc(trigdesc->numtriggers * sizeof(int));
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
(*tp)[n[TRIGGER_EVENT_INSERT]] = indx;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
(n[TRIGGER_EVENT_INSERT])++;
}
if (TRIGGER_FOR_DELETE(trigger->tgtype))
{
tp = &(t[TRIGGER_EVENT_DELETE]);
if (*tp == NULL)
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
*tp = (int *) palloc(trigdesc->numtriggers * sizeof(int));
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
(*tp)[n[TRIGGER_EVENT_DELETE]] = indx;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
(n[TRIGGER_EVENT_DELETE])++;
}
if (TRIGGER_FOR_UPDATE(trigger->tgtype))
{
tp = &(t[TRIGGER_EVENT_UPDATE]);
if (*tp == NULL)
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
*tp = (int *) palloc(trigdesc->numtriggers * sizeof(int));
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
(*tp)[n[TRIGGER_EVENT_UPDATE]] = indx;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
(n[TRIGGER_EVENT_UPDATE])++;
}
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
if (TRIGGER_FOR_TRUNCATE(trigger->tgtype))
{
tp = &(t[TRIGGER_EVENT_TRUNCATE]);
if (*tp == NULL)
*tp = (int *) palloc(trigdesc->numtriggers * sizeof(int));
(*tp)[n[TRIGGER_EVENT_TRUNCATE]] = indx;
(n[TRIGGER_EVENT_TRUNCATE])++;
}
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
/*
* Copy a TriggerDesc data structure.
*
* The copy is allocated in the current memory context.
*/
TriggerDesc *
CopyTriggerDesc(TriggerDesc *trigdesc)
{
TriggerDesc *newdesc;
uint16 *n;
int **t,
*tnew;
Trigger *trigger;
int i;
if (trigdesc == NULL || trigdesc->numtriggers <= 0)
return NULL;
newdesc = (TriggerDesc *) palloc(sizeof(TriggerDesc));
memcpy(newdesc, trigdesc, sizeof(TriggerDesc));
trigger = (Trigger *) palloc(trigdesc->numtriggers * sizeof(Trigger));
memcpy(trigger, trigdesc->triggers,
trigdesc->numtriggers * sizeof(Trigger));
newdesc->triggers = trigger;
for (i = 0; i < trigdesc->numtriggers; i++)
{
trigger->tgname = pstrdup(trigger->tgname);
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (trigger->tgnattr > 0)
{
int2 *newattr;
newattr = (int2 *) palloc(trigger->tgnattr * sizeof(int2));
memcpy(newattr, trigger->tgattr,
trigger->tgnattr * sizeof(int2));
trigger->tgattr = newattr;
}
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
if (trigger->tgnargs > 0)
{
pgindent run.
2003-08-04 02:43:34 +02:00
char **newargs;
int16 j;
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
newargs = (char **) palloc(trigger->tgnargs * sizeof(char *));
for (j = 0; j < trigger->tgnargs; j++)
newargs[j] = pstrdup(trigger->tgargs[j]);
trigger->tgargs = newargs;
}
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (trigger->tgqual)
trigger->tgqual = pstrdup(trigger->tgqual);
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
trigger++;
}
n = newdesc->n_before_statement;
t = newdesc->tg_before_statement;
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
{
if (n[i] > 0)
{
tnew = (int *) palloc(n[i] * sizeof(int));
memcpy(tnew, t[i], n[i] * sizeof(int));
t[i] = tnew;
}
else
t[i] = NULL;
}
n = newdesc->n_before_row;
t = newdesc->tg_before_row;
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
{
if (n[i] > 0)
{
tnew = (int *) palloc(n[i] * sizeof(int));
memcpy(tnew, t[i], n[i] * sizeof(int));
t[i] = tnew;
}
else
t[i] = NULL;
}
n = newdesc->n_after_row;
t = newdesc->tg_after_row;
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
{
if (n[i] > 0)
{
tnew = (int *) palloc(n[i] * sizeof(int));
memcpy(tnew, t[i], n[i] * sizeof(int));
t[i] = tnew;
}
else
t[i] = NULL;
}
n = newdesc->n_after_statement;
t = newdesc->tg_after_statement;
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
{
if (n[i] > 0)
{
tnew = (int *) palloc(n[i] * sizeof(int));
memcpy(tnew, t[i], n[i] * sizeof(int));
t[i] = tnew;
}
else
t[i] = NULL;
}
return newdesc;
}
/*
* Free a TriggerDesc data structure.
*/
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
void
FreeTriggerDesc(TriggerDesc *trigdesc)
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
int **t;
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
Trigger *trigger;
int i;
if (trigdesc == NULL)
return;
t = trigdesc->tg_before_statement;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
if (t[i] != NULL)
pfree(t[i]);
t = trigdesc->tg_before_row;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
if (t[i] != NULL)
pfree(t[i]);
t = trigdesc->tg_after_row;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
if (t[i] != NULL)
pfree(t[i]);
t = trigdesc->tg_after_statement;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
for (i = 0; i < TRIGGER_NUM_EVENT_CLASSES; i++)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
if (t[i] != NULL)
pfree(t[i]);
trigger = trigdesc->triggers;
for (i = 0; i < trigdesc->numtriggers; i++)
{
pfree(trigger->tgname);
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (trigger->tgnattr > 0)
pfree(trigger->tgattr);
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
if (trigger->tgnargs > 0)
{
while (--(trigger->tgnargs) >= 0)
pfree(trigger->tgargs[trigger->tgnargs]);
pfree(trigger->tgargs);
}
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (trigger->tgqual)
pfree(trigger->tgqual);
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
trigger++;
}
pfree(trigdesc->triggers);
pfree(trigdesc);
}
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
/*
* Compare two TriggerDesc structures for logical equality.
*/
#ifdef NOT_USED
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
bool
equalTriggerDescs(TriggerDesc *trigdesc1, TriggerDesc *trigdesc2)
{
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
int i,
j;
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* 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.
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.
2002-04-19 18:36:08 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* As of 7.3 we assume trigger set ordering is significant in the
* comparison; so we just compare corresponding slots of the two sets.
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
*
* Note: comparing the stringToNode forms of the WHEN clauses means that
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* parse column locations will affect the result. This is okay as long as
* this function is only used for detecting exact equality, as for example
* in checking for staleness of a cache entry.
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
*/
if (trigdesc1 != NULL)
{
if (trigdesc2 == NULL)
return false;
if (trigdesc1->numtriggers != trigdesc2->numtriggers)
return false;
for (i = 0; i < trigdesc1->numtriggers; i++)
{
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Trigger *trig1 = trigdesc1->triggers + i;
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.
2002-04-19 18:36:08 +02:00
Trigger *trig2 = trigdesc2->triggers + i;
if (trig1->tgoid != trig2->tgoid)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
return false;
if (strcmp(trig1->tgname, trig2->tgname) != 0)
return false;
if (trig1->tgfoid != trig2->tgfoid)
return false;
if (trig1->tgtype != trig2->tgtype)
return false;
if (trig1->tgenabled != trig2->tgenabled)
return false;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
if (trig1->tgisinternal != trig2->tgisinternal)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
return false;
Add tgconstrrelid to stored Trigger structures, make RI trigger functions depend on this rather than the trigger argument strings to locate the other relation to test. This makes RI triggers function properly in the presence of schemas and temp tables. Along the way, fix bogus lack of locking in RI triggers, handle quoting of names fully correctly, compute required sizes of query buffers with some semblance of accuracy.
2002-04-02 00:36:13 +02:00
if (trig1->tgconstrrelid != trig2->tgconstrrelid)
return false;
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
if (trig1->tgconstrindid != trig2->tgconstrindid)
return false;
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
if (trig1->tgconstraint != trig2->tgconstraint)
return false;
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
if (trig1->tgdeferrable != trig2->tgdeferrable)
return false;
if (trig1->tginitdeferred != trig2->tginitdeferred)
return false;
if (trig1->tgnargs != trig2->tgnargs)
return false;
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
if (trig1->tgnattr != trig2->tgnattr)
return false;
if (trig1->tgnattr > 0 &&
memcmp(trig1->tgattr, trig2->tgattr,
trig1->tgnattr * sizeof(int2)) != 0)
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
return false;
for (j = 0; j < trig1->tgnargs; j++)
if (strcmp(trig1->tgargs[j], trig2->tgargs[j]) != 0)
return false;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (trig1->tgqual == NULL && trig2->tgqual == NULL)
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
/* ok */ ;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
else if (trig1->tgqual == NULL || trig2->tgqual == NULL)
return false;
else if (strcmp(trig1->tgqual, trig2->tgqual) != 0)
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
return false;
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
}
}
else if (trigdesc2 != NULL)
return false;
return true;
}
pgindent run.
2003-08-04 02:43:34 +02:00
#endif /* NOT_USED */
Fix problems seen in parallel regress tests when SI buffer overruns (causing syscache and relcache flushes). Relcache entry rebuild now preserves original tupledesc, rewrite rules, and triggers if possible, so that pointers to these things remain valid --- if these things change while relcache entry has positive refcount, we elog(ERROR) to avoid later crash. Arrange for xact-local rels to be rebuilt when an SI inval message is seen for them, so that they are updated by CommandCounterIncrement the same as regular rels. (This is useful because of Hiroshi's recent changes to process our own SI messages at CommandCounterIncrement time.) This allows simplification of some routines that previously hacked around the lack of an automatic update. catcache now keeps its own copy of tupledesc for its relation, rather than depending on the relcache's copy; this avoids needing to reinitialize catcache during a cache flush, which saves some cycles and eliminates nasty circularity problems that occur if a cache flush happens while trying to initialize a catcache. Eliminate a number of permanent memory leaks that used to happen during catcache or relcache flush; not least of which was that catcache never freed any cached tuples! (Rule parsetree storage is still leaked, however; will fix that separately.) Nothing done yet about code that uses tuples retrieved by SearchSysCache for longer than is safe.
2000-01-31 05:35:57 +01:00
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
/*
* Call a trigger function.
*
* trigdata: trigger descriptor.
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
* tgindx: trigger's index in finfo and instr arrays.
* finfo: array of cached trigger function call information.
* instr: optional array of EXPLAIN ANALYZE instrumentation state.
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
* per_tuple_context: memory context to execute the function in.
*
* Returns the tuple (or NULL) as returned by the function.
*/
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
static HeapTuple
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
ExecCallTriggerFunc(TriggerData *trigdata,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
int tgindx,
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
FmgrInfo *finfo,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
Instrumentation *instr,
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
MemoryContext per_tuple_context)
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
{
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
FunctionCallInfoData fcinfo;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
PgStat_FunctionCallUsage fcusage;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Datum result;
MemoryContext oldContext;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
finfo += tgindx;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
/*
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* We cache fmgr lookup info, to avoid making the lookup again on each
* call.
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
*/
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
if (finfo->fn_oid == InvalidOid)
fmgr_info(trigdata->tg_trigger->tgfoid, finfo);
Assert(finfo->fn_oid == trigdata->tg_trigger->tgfoid);
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
/*
* If doing EXPLAIN ANALYZE, start charging time to this trigger.
*/
if (instr)
InstrStartNode(instr + tgindx);
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
/*
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
* Do the function evaluation in the per-tuple memory context, so that
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* leaked memory will be reclaimed once per tuple. Note in particular that
* any new tuple created by the trigger function will live till the end of
* the tuple cycle.
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
*/
oldContext = MemoryContextSwitchTo(per_tuple_context);
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
/*
* Call the function, passing no arguments but setting a context.
*/
Officially decouple FUNC_MAX_ARGS from INDEX_MAX_KEYS, and set the former to 100 by default. Clean up some of the less necessary dependencies on FUNC_MAX_ARGS; however, the biggie (FunctionCallInfoData) remains.
2005-03-29 05:01:32 +02:00
InitFunctionCallInfoData(fcinfo, finfo, 0, (Node *) trigdata, NULL);
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
pgstat_init_function_usage(&fcinfo, &fcusage);
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
result = FunctionCallInvoke(&fcinfo);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
pgstat_end_function_usage(&fcusage, true);
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
MemoryContextSwitchTo(oldContext);
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Trigger protocol allows function to return a null pointer, but NOT to
* set the isnull result flag.
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
*/
if (fcinfo.isnull)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("trigger function %u returned null value",
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
fcinfo.flinfo->fn_oid)));
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If doing EXPLAIN ANALYZE, stop charging time to this trigger, and count
* one "tuple returned" (really the number of firings).
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
*/
if (instr)
Make EXPLAIN sampling smarter, to avoid excessive sampling delay. Martijn van Oosterhout
2006-05-30 16:01:58 +02:00
InstrStopNode(instr + tgindx, 1);
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
return (HeapTuple) DatumGetPointer(result);
Now we are able to CREATE PROCEDURAL LANGUAGE (Thanks, Jan).
1997-10-28 16:11:45 +01:00
}
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
void
ExecBSInsertTriggers(EState *estate, ResultRelInfo *relinfo)
{
pgindent run.
2003-08-04 02:43:34 +02:00
TriggerDesc *trigdesc;
int ntrigs;
int *tgindx;
int i;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
TriggerData LocTriggerData;
trigdesc = relinfo->ri_TrigDesc;
if (trigdesc == NULL)
return;
ntrigs = trigdesc->n_before_statement[TRIGGER_EVENT_INSERT];
tgindx = trigdesc->tg_before_statement[TRIGGER_EVENT_INSERT];
if (ntrigs == 0)
return;
LocTriggerData.type = T_TriggerData;
LocTriggerData.tg_event = TRIGGER_EVENT_INSERT |
pgindent run.
2003-08-04 02:43:34 +02:00
TRIGGER_EVENT_BEFORE;
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
LocTriggerData.tg_trigtuple = NULL;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_newtuple = NULL;
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
for (i = 0; i < ntrigs; i++)
{
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
HeapTuple newtuple;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
NULL, NULL, NULL))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
GetPerTupleMemoryContext(estate));
if (newtuple)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("BEFORE STATEMENT trigger cannot return a value")));
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
}
}
void
ExecASInsertTriggers(EState *estate, ResultRelInfo *relinfo)
{
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
if (trigdesc && trigdesc->n_after_statement[TRIGGER_EVENT_INSERT] > 0)
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_INSERT,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
false, NULL, NULL, NIL, NULL);
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
}
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
HeapTuple
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
ExecBRInsertTriggers(EState *estate, ResultRelInfo *relinfo,
HeapTuple trigtuple)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
int ntrigs = trigdesc->n_before_row[TRIGGER_EVENT_INSERT];
int *tgindx = trigdesc->tg_before_row[TRIGGER_EVENT_INSERT];
Cleanups.
1997-09-11 09:24:37 +02:00
HeapTuple newtuple = trigtuple;
HeapTuple oldtuple;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
TriggerData LocTriggerData;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
int i;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.type = T_TriggerData;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
LocTriggerData.tg_event = TRIGGER_EVENT_INSERT |
pgindent run.
2003-08-04 02:43:34 +02:00
TRIGGER_EVENT_ROW |
TRIGGER_EVENT_BEFORE;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.tg_newtuple = NULL;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
for (i = 0; i < ntrigs; i++)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
NULL, NULL, newtuple))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.tg_trigtuple = oldtuple = newtuple;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
GetPerTupleMemoryContext(estate));
if (oldtuple != newtuple && oldtuple != trigtuple)
heap_freetuple(oldtuple);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
if (newtuple == NULL)
break;
}
Renaming cleanup, no pgindent yet.
1998-09-01 05:29:17 +02:00
return newtuple;
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
void
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
ExecARInsertTriggers(EState *estate, ResultRelInfo *relinfo,
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
HeapTuple trigtuple, List *recheckIndexes)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
if (trigdesc && trigdesc->n_after_row[TRIGGER_EVENT_INSERT] > 0)
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_INSERT,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
true, NULL, trigtuple, recheckIndexes, NULL);
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
}
void
ExecBSDeleteTriggers(EState *estate, ResultRelInfo *relinfo)
{
pgindent run.
2003-08-04 02:43:34 +02:00
TriggerDesc *trigdesc;
int ntrigs;
int *tgindx;
int i;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
TriggerData LocTriggerData;
trigdesc = relinfo->ri_TrigDesc;
if (trigdesc == NULL)
return;
ntrigs = trigdesc->n_before_statement[TRIGGER_EVENT_DELETE];
tgindx = trigdesc->tg_before_statement[TRIGGER_EVENT_DELETE];
if (ntrigs == 0)
return;
LocTriggerData.type = T_TriggerData;
LocTriggerData.tg_event = TRIGGER_EVENT_DELETE |
pgindent run.
2003-08-04 02:43:34 +02:00
TRIGGER_EVENT_BEFORE;
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
LocTriggerData.tg_trigtuple = NULL;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_newtuple = NULL;
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
for (i = 0; i < ntrigs; i++)
{
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
HeapTuple newtuple;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
NULL, NULL, NULL))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
GetPerTupleMemoryContext(estate));
if (newtuple)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("BEFORE STATEMENT trigger cannot return a value")));
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
}
}
void
ExecASDeleteTriggers(EState *estate, ResultRelInfo *relinfo)
{
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
if (trigdesc && trigdesc->n_after_statement[TRIGGER_EVENT_DELETE] > 0)
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_DELETE,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
false, NULL, NULL, NIL, NULL);
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
bool
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
ExecBRDeleteTriggers(EState *estate, EPQState *epqstate,
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
ResultRelInfo *relinfo,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
ItemPointer tupleid)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
int ntrigs = trigdesc->n_before_row[TRIGGER_EVENT_DELETE];
int *tgindx = trigdesc->tg_before_row[TRIGGER_EVENT_DELETE];
Fix ExecBRDeleteTriggers so that deletion is not suppressed when delete triggers exist but are all disabled. Problem noted by Gavin Sherry in original discussion of enable/disable trigger patch, but was never addressed.
2005-08-24 19:38:35 +02:00
bool result = true;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
TriggerData LocTriggerData;
pgindent run over code.
1999-05-25 18:15:34 +02:00
HeapTuple trigtuple;
Fix ExecBRDeleteTriggers so that deletion is not suppressed when delete triggers exist but are all disabled. Problem noted by Gavin Sherry in original discussion of enable/disable trigger patch, but was never addressed.
2005-08-24 19:38:35 +02:00
HeapTuple newtuple;
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
TupleTableSlot *newSlot;
pgindent run over code.
1999-05-25 18:15:34 +02:00
int i;
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
trigtuple = GetTupleForTrigger(estate, epqstate, relinfo, tupleid,
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
&newSlot);
Cleanups.
1997-09-11 09:24:37 +02:00
if (trigtuple == NULL)
Renaming cleanup, no pgindent yet.
1998-09-01 05:29:17 +02:00
return false;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.type = T_TriggerData;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
LocTriggerData.tg_event = TRIGGER_EVENT_DELETE |
pgindent run.
2003-08-04 02:43:34 +02:00
TRIGGER_EVENT_ROW |
TRIGGER_EVENT_BEFORE;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.tg_newtuple = NULL;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
Cleanups.
1997-09-11 09:24:37 +02:00
for (i = 0; i < ntrigs; i++)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
NULL, trigtuple, NULL))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.tg_trigtuple = trigtuple;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
GetPerTupleMemoryContext(estate));
Cleanups.
1997-09-11 09:24:37 +02:00
if (newtuple == NULL)
Fix ExecBRDeleteTriggers so that deletion is not suppressed when delete triggers exist but are all disabled. Problem noted by Gavin Sherry in original discussion of enable/disable trigger patch, but was never addressed.
2005-08-24 19:38:35 +02:00
{
result = false; /* tell caller to suppress delete */
Cleanups.
1997-09-11 09:24:37 +02:00
break;
Fix ExecBRDeleteTriggers so that deletion is not suppressed when delete triggers exist but are all disabled. Problem noted by Gavin Sherry in original discussion of enable/disable trigger patch, but was never addressed.
2005-08-24 19:38:35 +02:00
}
Fixed growing of backend due to not pfree()'d data on COPY FROM Fixed growing of backend if BEFORE DELETE trigger returns heap tuple different from trigtuple. Jan
1999-02-01 21:25:55 +01:00
if (newtuple != trigtuple)
Some changes to prepare for LONG attributes. Jan
1999-12-16 23:20:03 +01:00
heap_freetuple(newtuple);
Cleanups.
1997-09-11 09:24:37 +02:00
}
Some changes to prepare for LONG attributes. Jan
1999-12-16 23:20:03 +01:00
heap_freetuple(trigtuple);
Cleanups.
1997-09-11 09:24:37 +02:00
Fix ExecBRDeleteTriggers so that deletion is not suppressed when delete triggers exist but are all disabled. Problem noted by Gavin Sherry in original discussion of enable/disable trigger patch, but was never addressed.
2005-08-24 19:38:35 +02:00
return result;
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
void
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
ExecARDeleteTriggers(EState *estate, ResultRelInfo *relinfo,
ItemPointer tupleid)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
Cleanups.
1997-09-11 09:24:37 +02:00
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
if (trigdesc && trigdesc->n_after_row[TRIGGER_EVENT_DELETE] > 0)
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
{
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
HeapTuple trigtuple = GetTupleForTrigger(estate, NULL, relinfo,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
tupleid, NULL);
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_DELETE,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
true, trigtuple, NULL, NIL, NULL);
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
heap_freetuple(trigtuple);
}
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
void
ExecBSUpdateTriggers(EState *estate, ResultRelInfo *relinfo)
{
pgindent run.
2003-08-04 02:43:34 +02:00
TriggerDesc *trigdesc;
int ntrigs;
int *tgindx;
int i;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
TriggerData LocTriggerData;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Bitmapset *modifiedCols;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
trigdesc = relinfo->ri_TrigDesc;
if (trigdesc == NULL)
return;
ntrigs = trigdesc->n_before_statement[TRIGGER_EVENT_UPDATE];
tgindx = trigdesc->tg_before_statement[TRIGGER_EVENT_UPDATE];
if (ntrigs == 0)
return;
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
modifiedCols = GetModifiedColumns(relinfo, estate);
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
LocTriggerData.type = T_TriggerData;
LocTriggerData.tg_event = TRIGGER_EVENT_UPDATE |
pgindent run.
2003-08-04 02:43:34 +02:00
TRIGGER_EVENT_BEFORE;
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
LocTriggerData.tg_trigtuple = NULL;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_newtuple = NULL;
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
for (i = 0; i < ntrigs; i++)
{
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
HeapTuple newtuple;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
modifiedCols, NULL, NULL))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
GetPerTupleMemoryContext(estate));
if (newtuple)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("BEFORE STATEMENT trigger cannot return a value")));
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
}
}
void
ExecASUpdateTriggers(EState *estate, ResultRelInfo *relinfo)
{
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
if (trigdesc && trigdesc->n_after_statement[TRIGGER_EVENT_UPDATE] > 0)
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_UPDATE,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
false, NULL, NULL, NIL,
GetModifiedColumns(relinfo, estate));
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
}
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
HeapTuple
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
ResultRelInfo *relinfo,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
ItemPointer tupleid, HeapTuple newtuple)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
int ntrigs = trigdesc->n_before_row[TRIGGER_EVENT_UPDATE];
int *tgindx = trigdesc->tg_before_row[TRIGGER_EVENT_UPDATE];
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
TriggerData LocTriggerData;
pgindent run over code.
1999-05-25 18:15:34 +02:00
HeapTuple trigtuple;
HeapTuple oldtuple;
HeapTuple intuple = newtuple;
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
TupleTableSlot *newSlot;
pgindent run over code.
1999-05-25 18:15:34 +02:00
int i;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Bitmapset *modifiedCols;
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
trigtuple = GetTupleForTrigger(estate, epqstate, relinfo, tupleid,
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
&newSlot);
Cleanups.
1997-09-11 09:24:37 +02:00
if (trigtuple == NULL)
Renaming cleanup, no pgindent yet.
1998-09-01 05:29:17 +02:00
return NULL;
Cleanups.
1997-09-11 09:24:37 +02:00
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
/*
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
* In READ COMMITTED isolation level it's possible that newtuple was
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
* changed due to concurrent update. In that case we have a raw subplan
* output tuple and need to run it through the junk filter.
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
*/
if (newSlot != NULL)
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
intuple = newtuple = ExecRemoveJunk(relinfo->ri_junkFilter, newSlot);
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
modifiedCols = GetModifiedColumns(relinfo, estate);
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.type = T_TriggerData;
This trivial patch implements disabled, deferred triggers, per my proposal on -hackers a couple days ago. The 'tgenabled' status of the trigger is consulted when the trigger is added to the deferred queue (i.e. when the event occurs that fires the trigger), not when the deferred event is executed. No regression tests, as another bug prevents them (the pg_trigger row for a trigger is only loaded once per session, so any changes to it are not noticed unless the client disconnects and reconnects). Neil Conway
2003-01-08 23:28:32 +01:00
LocTriggerData.tg_event = TRIGGER_EVENT_UPDATE |
pgindent run.
2003-08-04 02:43:34 +02:00
TRIGGER_EVENT_ROW |
TRIGGER_EVENT_BEFORE;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
Cleanups.
1997-09-11 09:24:37 +02:00
for (i = 0; i < ntrigs; i++)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
modifiedCols, trigtuple, newtuple))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.tg_trigtuple = trigtuple;
LocTriggerData.tg_newtuple = oldtuple = newtuple;
I found a corner case in which it is possible for RI_FKey_check's call of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple: if the row was updated or deleted by a subtransaction of my own transaction that was later rolled back. This cannot occur in pre-8.0 of course, so the hint-bit patch applied a couple weeks ago is OK for existing releases. But for 8.0 it seems we had better fix things so that RI_FKey_check can pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly, add fields to the TriggerData struct to carry the buffer ID(s) for the old and new tuple(s). There are other possible solutions but this one seems cleanest; it will allow other AFTER-trigger functions to safely do tqual.c calls if they want to. Put new fields at end of struct so that there is no API breakage.
2004-10-30 22:53:06 +02:00
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
GetPerTupleMemoryContext(estate));
if (oldtuple != newtuple && oldtuple != intuple)
heap_freetuple(oldtuple);
Cleanups.
1997-09-11 09:24:37 +02:00
if (newtuple == NULL)
break;
}
Some changes to prepare for LONG attributes. Jan
1999-12-16 23:20:03 +01:00
heap_freetuple(trigtuple);
Renaming cleanup, no pgindent yet.
1998-09-01 05:29:17 +02:00
return newtuple;
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
void
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
ExecARUpdateTriggers(EState *estate, ResultRelInfo *relinfo,
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
ItemPointer tupleid, HeapTuple newtuple,
List *recheckIndexes)
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
if (trigdesc && trigdesc->n_after_row[TRIGGER_EVENT_UPDATE] > 0)
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
{
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
HeapTuple trigtuple = GetTupleForTrigger(estate, NULL, relinfo,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
tupleid, NULL);
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_UPDATE,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
true, trigtuple, newtuple, recheckIndexes,
GetModifiedColumns(relinfo, estate));
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
heap_freetuple(trigtuple);
}
BEFORE/AFTER ROW INSERT triggers startup from CopyFrom() RelationBuildTriggers() & FreeTriggerDesc() in trigger.c
1997-09-01 09:59:06 +02:00
}
Cleanups.
1997-09-11 09:24:37 +02:00
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
void
ExecBSTruncateTriggers(EState *estate, ResultRelInfo *relinfo)
{
TriggerDesc *trigdesc;
int ntrigs;
int *tgindx;
int i;
TriggerData LocTriggerData;
trigdesc = relinfo->ri_TrigDesc;
if (trigdesc == NULL)
return;
ntrigs = trigdesc->n_before_statement[TRIGGER_EVENT_TRUNCATE];
tgindx = trigdesc->tg_before_statement[TRIGGER_EVENT_TRUNCATE];
if (ntrigs == 0)
return;
LocTriggerData.type = T_TriggerData;
LocTriggerData.tg_event = TRIGGER_EVENT_TRUNCATE |
TRIGGER_EVENT_BEFORE;
LocTriggerData.tg_relation = relinfo->ri_RelationDesc;
LocTriggerData.tg_trigtuple = NULL;
LocTriggerData.tg_newtuple = NULL;
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
for (i = 0; i < ntrigs; i++)
{
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
HeapTuple newtuple;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, LocTriggerData.tg_event,
NULL, NULL, NULL))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
tgindx[i],
relinfo->ri_TrigFunctions,
relinfo->ri_TrigInstrument,
GetPerTupleMemoryContext(estate));
if (newtuple)
ereport(ERROR,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
errmsg("BEFORE STATEMENT trigger cannot return a value")));
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
}
}
void
ExecASTruncateTriggers(EState *estate, ResultRelInfo *relinfo)
{
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
if (trigdesc && trigdesc->n_after_statement[TRIGGER_EVENT_TRUNCATE] > 0)
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(estate, relinfo, TRIGGER_EVENT_TRUNCATE,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
false, NULL, NULL, NIL, NULL);
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
}
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
Cleanups.
1997-09-11 09:24:37 +02:00
static HeapTuple
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
GetTupleForTrigger(EState *estate,
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
EPQState *epqstate,
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
ResultRelInfo *relinfo,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
ItemPointer tid,
GetTupleForTrigger must use outer transaction's command counter for time qual checking, not GetCurrentCommandId. Per test case from Steve Wolfe.
2003-03-27 15:33:11 +01:00
TupleTableSlot **newSlot)
Cleanups.
1997-09-11 09:24:37 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
Relation relation = relinfo->ri_RelationDesc;
pgindent run over code.
1999-05-25 18:15:34 +02:00
HeapTupleData tuple;
HeapTuple result;
Buffer buffer;
Cleanups.
1997-09-11 09:24:37 +02:00
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
if (newSlot != NULL)
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
HTSU_Result test;
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
ItemPointerData update_ctid;
TransactionId update_xmax;
*newSlot = NULL;
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
/* caller must pass an epqstate if EvalPlanQual is possible */
Assert(epqstate != NULL);
Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c. They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
2009-10-10 03:43:50 +02:00
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
/*
Implement sharable row-level locks, and use them for foreign key references to eliminate unnecessary deadlocks. This commit adds SELECT ... FOR SHARE paralleling SELECT ... FOR UPDATE. The implementation uses a new SLRU data structure (managed much like pg_subtrans) to represent multiple- transaction-ID sets. When more than one transaction is holding a shared lock on a particular row, we create a MultiXactId representing that set of transactions and store its ID in the row's XMAX. This scheme allows an effectively unlimited number of row locks, just as we did before, while not costing any extra overhead except when a shared lock actually has to be shared. Still TODO: use the regular lock manager to control the grant order when multiple backends are waiting for a row lock. Alvaro Herrera and Tom Lane.
2005-04-28 23:47:18 +02:00
* lock tuple for update
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
*/
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
ltrmark:;
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
tuple.t_self = *tid;
test = heap_lock_tuple(relation, &tuple, &buffer,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
&update_ctid, &update_xmax,
estate->es_output_cid,
Add NOWAIT option to SELECT FOR UPDATE/SHARE. Original patch by Hans-Juergen Schoenig, revisions by Karel Zak and Tom Lane.
2005-08-01 22:31:16 +02:00
LockTupleExclusive, false);
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
switch (test)
{
case HeapTupleSelfUpdated:
Further thinking about heap_mark4update: in HeapTupleSelfUpdated case, executor should not return the tuple as successfully marked, because in fact it's been deleted. Not clear that this case has ever been seen in practice (I think you'd have to write a SELECT FOR UPDATE that calls a function that deletes some row the SELECT will visit later...) but we should be consistent. Also add comments to several other places that got it right but didn't explain what they were doing.
2002-09-24 00:57:44 +02:00
/* treat it as deleted; do not process */
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
ReleaseBuffer(buffer);
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
return NULL;
Cleanups.
1997-09-11 09:24:37 +02:00
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
case HeapTupleMayBeUpdated:
break;
Cleanups.
1997-09-11 09:24:37 +02:00
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
case HeapTupleUpdated:
ReleaseBuffer(buffer);
Implement isolation levels read uncommitted and repeatable read as acting like the next higher one.
2003-11-06 23:08:15 +01:00
if (IsXactIsoLevelSerializable)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
A visit from the message-style police ...
2003-07-28 02:09:16 +02:00
errmsg("could not serialize access due to concurrent update")));
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
if (!ItemPointerEquals(&update_ctid, &tuple.t_self))
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
{
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
/* it was updated, so look at the updated version */
TupleTableSlot *epqslot;
epqslot = EvalPlanQual(estate,
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
epqstate,
relation,
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
relinfo->ri_RangeTableIndex,
&update_ctid,
Avoid incrementing the CommandCounter when CommandCounterIncrement is called but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
2007-11-30 22:22:54 +01:00
update_xmax);
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
if (!TupIsNull(epqslot))
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
{
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
*tid = update_ctid;
Hope that execMain.c good merged. Fix for BEFORE ROW UPDATE triggers: result tuple may be different (due to concurrent update) from one initially produced by top level plan.
1999-01-29 12:56:01 +01:00
*newSlot = epqslot;
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
/*
* EvalPlanQual already locked the tuple, but we
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* re-call heap_lock_tuple anyway as an easy way of
* re-fetching the correct tuple. Speed is hardly a
* criterion in this path anyhow.
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
*/
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
goto ltrmark;
}
}
pgindent run over code.
1999-05-25 18:15:34 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* if tuple was deleted or PlanQual failed for updated tuple -
Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
* we must not process this tuple!
READ COMMITTED isolevel is implemented and is default now.
1999-01-29 10:23:17 +01:00
*/
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
return NULL;
Cleanups.
1997-09-11 09:24:37 +02:00
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
default:
ReleaseBuffer(buffer);
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
elog(ERROR, "unrecognized heap_lock_tuple status: %u", test);
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
return NULL; /* keep compiler quiet */
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
}
}
else
{
Clean up the use of some page-header-access macros: principally, use SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that makes the code clearer, and avoid casting between Page and PageHeader where possible. Zdenek Kotala, with some additional cleanup by Heikki Linnakangas. I did not apply the parts of the proposed patch that would have resulted in slightly changing the on-disk format of hash indexes; it seems to me that's not a win as long as there's any chance of having in-place upgrade for 8.4.
2008-07-13 22:45:47 +02:00
Page page;
pgindent run over code.
1999-05-25 18:15:34 +02:00
ItemId lp;
Cleanups.
1997-09-11 09:24:37 +02:00
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
buffer = ReadBuffer(relation, ItemPointerGetBlockNumber(tid));
Cleanups.
1997-09-11 09:24:37 +02:00
Clean up the use of some page-header-access macros: principally, use SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that makes the code clearer, and avoid casting between Page and PageHeader where possible. Zdenek Kotala, with some additional cleanup by Heikki Linnakangas. I did not apply the parts of the proposed patch that would have resulted in slightly changing the on-disk format of hash indexes; it seems to me that's not a win as long as there's any chance of having in-place upgrade for 8.4.
2008-07-13 22:45:47 +02:00
page = BufferGetPage(buffer);
lp = PageGetItemId(page, ItemPointerGetOffsetNumber(tid));
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
Redefine the lp_flags field of item pointers as having four states, rather than two independent bits (one of which was never used in heap pages anyway, or at least hadn't been in a very long time). This gives us flexibility to add the HOT notions of redirected and dead item pointers without requiring anything so klugy as magic values of lp_off and lp_len. The state values are chosen so that for the states currently in use (pre-HOT) there is no change in the physical representation.
2007-09-13 00:10:26 +02:00
Assert(ItemIdIsNormal(lp));
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
Clean up the use of some page-header-access macros: principally, use SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that makes the code clearer, and avoid casting between Page and PageHeader where possible. Zdenek Kotala, with some additional cleanup by Heikki Linnakangas. I did not apply the parts of the proposed patch that would have resulted in slightly changing the on-disk format of hash indexes; it seems to me that's not a win as long as there's any chance of having in-place upgrade for 8.4.
2008-07-13 22:45:47 +02:00
tuple.t_data = (HeapTupleHeader) PageGetItem(page, lp);
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
tuple.t_len = ItemIdGetLength(lp);
tuple.t_self = *tid;
Repair problems with VACUUM destroying t_ctid chains too soon, and with insufficient paranoia in code that follows t_ctid links. (We must do both because even with VACUUM doing it properly, the intermediate state with a dangling t_ctid link is visible concurrently during lazy VACUUM, and could be seen afterwards if either type of VACUUM crashes partway through.) Also try to improve documentation about what's going on. Patch is a bit bulky because passing the XMAX information around required changing the APIs of some low-level heapam.c routines, but it's not conceptually very complicated. Per trouble report from Teodor and subsequent analysis. This needs to be back-patched, but I'll do that after 8.1 beta is out.
2005-08-20 02:40:32 +02:00
tuple.t_tableOid = RelationGetRelid(relation);
Cleanups.
1997-09-11 09:24:37 +02:00
}
New HeapTuple structure/interface.
1998-11-27 20:52:36 +01:00
result = heap_copytuple(&tuple);
Initial MVCC code. New code for locking buffer' context.
1998-12-15 13:47:01 +01:00
ReleaseBuffer(buffer);
Cleanups.
1997-09-11 09:24:37 +02:00
New HeapTuple structure/interface.
1998-11-27 20:52:36 +01:00
return result;
Cleanups.
1997-09-11 09:24:37 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
/*
* Is trigger enabled to fire?
*/
static bool
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
TriggerEnabled(EState *estate, ResultRelInfo *relinfo,
Trigger *trigger, TriggerEvent event,
Bitmapset *modifiedCols,
HeapTuple oldtup, HeapTuple newtup)
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
{
/* Check replication-role-dependent enable state */
if (SessionReplicationRole == SESSION_REPLICATION_ROLE_REPLICA)
{
if (trigger->tgenabled == TRIGGER_FIRES_ON_ORIGIN ||
trigger->tgenabled == TRIGGER_DISABLED)
return false;
}
else /* ORIGIN or LOCAL role */
{
if (trigger->tgenabled == TRIGGER_FIRES_ON_REPLICA ||
trigger->tgenabled == TRIGGER_DISABLED)
return false;
}
/*
* Check for column-specific trigger (only possible for UPDATE, and in
* fact we *must* ignore tgattr for other event types)
*/
if (trigger->tgnattr > 0 && TRIGGER_FIRED_BY_UPDATE(event))
{
int i;
bool modified;
modified = false;
for (i = 0; i < trigger->tgnattr; i++)
{
if (bms_is_member(trigger->tgattr[i] - FirstLowInvalidHeapAttributeNumber,
modifiedCols))
{
modified = true;
break;
}
}
if (!modified)
return false;
}
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
/* Check for WHEN clause */
if (trigger->tgqual)
{
TupleDesc tupdesc = RelationGetDescr(relinfo->ri_RelationDesc);
List **predicate;
ExprContext *econtext;
TupleTableSlot *oldslot = NULL;
TupleTableSlot *newslot = NULL;
MemoryContext oldContext;
int i;
Assert(estate != NULL);
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* trigger is an element of relinfo->ri_TrigDesc->triggers[]; find the
* matching element of relinfo->ri_TrigWhenExprs[]
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
*/
i = trigger - relinfo->ri_TrigDesc->triggers;
predicate = &relinfo->ri_TrigWhenExprs[i];
/*
* If first time through for this WHEN expression, build expression
* nodetrees for it. Keep them in the per-query memory context so
* they'll survive throughout the query.
*/
if (*predicate == NIL)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Node *tgqual;
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
oldContext = MemoryContextSwitchTo(estate->es_query_cxt);
tgqual = stringToNode(trigger->tgqual);
/* Change references to OLD and NEW to INNER and OUTER */
ChangeVarNodes(tgqual, PRS2_OLD_VARNO, INNER, 0);
ChangeVarNodes(tgqual, PRS2_NEW_VARNO, OUTER, 0);
/* ExecQual wants implicit-AND form */
tgqual = (Node *) make_ands_implicit((Expr *) tgqual);
*predicate = (List *) ExecPrepareExpr((Expr *) tgqual, estate);
MemoryContextSwitchTo(oldContext);
}
/*
* We will use the EState's per-tuple context for evaluating WHEN
* expressions (creating it if it's not already there).
*/
econtext = GetPerTupleExprContext(estate);
/*
* Put OLD and NEW tuples into tupleslots for expression evaluation.
* These slots can be shared across the whole estate, but be careful
* that they have the current resultrel's tupdesc.
*/
if (HeapTupleIsValid(oldtup))
{
if (estate->es_trig_oldtup_slot == NULL)
{
oldContext = MemoryContextSwitchTo(estate->es_query_cxt);
estate->es_trig_oldtup_slot = ExecInitExtraTupleSlot(estate);
MemoryContextSwitchTo(oldContext);
}
oldslot = estate->es_trig_oldtup_slot;
if (oldslot->tts_tupleDescriptor != tupdesc)
ExecSetSlotDescriptor(oldslot, tupdesc);
ExecStoreTuple(oldtup, oldslot, InvalidBuffer, false);
}
if (HeapTupleIsValid(newtup))
{
if (estate->es_trig_tuple_slot == NULL)
{
oldContext = MemoryContextSwitchTo(estate->es_query_cxt);
estate->es_trig_tuple_slot = ExecInitExtraTupleSlot(estate);
MemoryContextSwitchTo(oldContext);
}
newslot = estate->es_trig_tuple_slot;
if (newslot->tts_tupleDescriptor != tupdesc)
ExecSetSlotDescriptor(newslot, tupdesc);
ExecStoreTuple(newtup, newslot, InvalidBuffer, false);
}
/*
* Finally evaluate the expression, making the old and/or new tuples
* available as INNER/OUTER respectively.
*/
econtext->ecxt_innertuple = oldslot;
econtext->ecxt_outertuple = newslot;
if (!ExecQual(*predicate, econtext, false))
return false;
}
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
return true;
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* After-trigger stuff
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* The AfterTriggersData struct holds data about pending AFTER trigger events
* during the current transaction tree. (BEFORE triggers are fired
* immediately so we don't need any persistent state about them.) The struct
* and most of its subsidiary data are kept in TopTransactionContext; however
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* the individual event records are kept in a separate sub-context. This is
* done mainly so that it's easy to tell from a memory context dump how much
* space is being eaten by trigger events.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Because the list of pending events can grow large, we go to some
* considerable effort to minimize per-event memory consumption. The event
* records are grouped into chunks and common data for similar events in the
* same chunk is only stored once.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*
* XXX We need to be able to save the per-event data in a file if it grows too
* large.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* Per-trigger SET CONSTRAINT status */
typedef struct SetConstraintTriggerData
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Oid sct_tgoid;
bool sct_tgisdeferred;
} SetConstraintTriggerData;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
typedef struct SetConstraintTriggerData *SetConstraintTrigger;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* SET CONSTRAINT intra-transaction status.
Remove 'triggered data change violation' error check, per recent discussions in pghackers.
2001-11-16 17:31:16 +01:00
*
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
* We make this a single palloc'd object so it can be copied and freed easily.
pgindent run.
2003-08-04 02:43:34 +02:00
*
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
* all_isset and all_isdeferred are used to keep track
* of SET CONSTRAINTS ALL {DEFERRED, IMMEDIATE}.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
* trigstates[] stores per-trigger tgisdeferred settings.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
typedef struct SetConstraintStateData
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
bool all_isset;
bool all_isdeferred;
int numstates; /* number of trigstates[] entries in use */
int numalloc; /* allocated size of trigstates[] */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
SetConstraintTriggerData trigstates[1]; /* VARIABLE LENGTH ARRAY */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
} SetConstraintStateData;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
typedef SetConstraintStateData *SetConstraintState;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
* Per-trigger-event data
*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* The actual per-event data, AfterTriggerEventData, includes DONE/IN_PROGRESS
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* status bits and one or two tuple CTIDs. Each event record also has an
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* associated AfterTriggerSharedData that is shared across all instances
* of similar events within a "chunk".
*
* We arrange not to waste storage on ate_ctid2 for non-update events.
* We could go further and not store either ctid for statement-level triggers,
* but that seems unlikely to be worth the trouble.
*
* Note: ats_firing_id is initially zero and is set to something else when
* AFTER_TRIGGER_IN_PROGRESS is set. It indicates which trigger firing
* cycle the trigger will be fired in (or was fired in, if DONE is set).
* Although this is mutable state, we can keep it in AfterTriggerSharedData
* because all instances of the same type of event in a given event list will
* be fired at the same time, if they were queued between the same firing
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* cycles. So we need only ensure that ats_firing_id is zero when attaching
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* a new event to an existing AfterTriggerSharedData record.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
typedef uint32 TriggerFlags;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
#define AFTER_TRIGGER_OFFSET 0x0FFFFFFF /* must be low-order
* bits */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
#define AFTER_TRIGGER_2CTIDS 0x10000000
#define AFTER_TRIGGER_DONE 0x20000000
#define AFTER_TRIGGER_IN_PROGRESS 0x40000000
typedef struct AfterTriggerSharedData *AfterTriggerShared;
typedef struct AfterTriggerSharedData
{
TriggerEvent ats_event; /* event type indicator, see trigger.h */
Oid ats_tgoid; /* the trigger's ID */
Oid ats_relid; /* the relation it's on */
CommandId ats_firing_id; /* ID for firing cycle */
} AfterTriggerSharedData;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
typedef struct AfterTriggerEventData *AfterTriggerEvent;
In an attempt to simplify my life I'm submitting this patch that restructures the deferred trigger queue. The fundamental change is to put all the static variables to hold the deferred triggers in a single structure. Alvaro Herrera
2003-06-25 01:25:44 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
typedef struct AfterTriggerEventData
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
TriggerFlags ate_flags; /* status bits and offset to shared data */
ItemPointerData ate_ctid1; /* inserted, deleted, or old updated tuple */
ItemPointerData ate_ctid2; /* new updated tuple */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
} AfterTriggerEventData;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* This struct must exactly match the one above except for not having ctid2 */
typedef struct AfterTriggerEventDataOneCtid
{
TriggerFlags ate_flags; /* status bits and offset to shared data */
ItemPointerData ate_ctid1; /* inserted, deleted, or old updated tuple */
} AfterTriggerEventDataOneCtid;
#define SizeofTriggerEvent(evt) \
(((evt)->ate_flags & AFTER_TRIGGER_2CTIDS) ? \
sizeof(AfterTriggerEventData) : sizeof(AfterTriggerEventDataOneCtid))
#define GetTriggerSharedData(evt) \
((AfterTriggerShared) ((char *) (evt) + ((evt)->ate_flags & AFTER_TRIGGER_OFFSET)))
/*
* To avoid palloc overhead, we keep trigger events in arrays in successively-
* larger chunks (a slightly more sophisticated version of an expansible
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* array). The space between CHUNK_DATA_START and freeptr is occupied by
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* AfterTriggerEventData records; the space between endfree and endptr is
* occupied by AfterTriggerSharedData records.
*/
typedef struct AfterTriggerEventChunk
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
struct AfterTriggerEventChunk *next; /* list link */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
char *freeptr; /* start of free space in chunk */
char *endfree; /* end of free space in chunk */
char *endptr; /* end of chunk */
/* event data follows here */
} AfterTriggerEventChunk;
#define CHUNK_DATA_START(cptr) ((char *) (cptr) + MAXALIGN(sizeof(AfterTriggerEventChunk)))
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* A list of events */
typedef struct AfterTriggerEventList
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEventChunk *head;
AfterTriggerEventChunk *tail;
char *tailfree; /* freeptr of tail chunk */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
} AfterTriggerEventList;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* Macros to help in iterating over a list of events */
#define for_each_chunk(cptr, evtlist) \
for (cptr = (evtlist).head; cptr != NULL; cptr = cptr->next)
#define for_each_event(eptr, cptr) \
for (eptr = (AfterTriggerEvent) CHUNK_DATA_START(cptr); \
(char *) eptr < (cptr)->freeptr; \
eptr = (AfterTriggerEvent) (((char *) eptr) + SizeofTriggerEvent(eptr)))
/* Use this if no special per-chunk processing is needed */
#define for_each_event_chunk(eptr, cptr, evtlist) \
for_each_chunk(cptr, evtlist) for_each_event(eptr, cptr)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
* All per-transaction data for the AFTER TRIGGERS module.
*
* AfterTriggersData has the following fields:
*
* firing_counter is incremented for each call of afterTriggerInvokeEvents.
* We mark firable events with the current firing cycle's ID so that we can
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* tell which ones to work on. This ensures sane behavior if a trigger
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* function chooses to do SET CONSTRAINTS: the inner SET CONSTRAINTS will
* only fire those events that weren't already scheduled for firing.
*
* state keeps track of the transaction-local effects of SET CONSTRAINTS.
* This is saved and restored across failed subtransactions.
*
* events is the current list of deferred events. This is global across
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* all subtransactions of the current transaction. In a subtransaction
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* abort, we know that the events added by the subtransaction are at the
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
* end of the list, so it is relatively easy to discard them. The event
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* list chunks themselves are stored in event_cxt.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*
* query_depth is the current depth of nested AfterTriggerBeginQuery calls
* (-1 when the stack is empty).
*
* query_stack[query_depth] is a list of AFTER trigger events queued by the
* current query (and the query_stack entries below it are lists of trigger
* events queued by calling queries). None of these are valid until the
* matching AfterTriggerEndQuery call occurs. At that point we fire
* immediate-mode triggers, and append any deferred events to the main events
* list.
*
* maxquerydepth is just the allocated length of query_stack.
*
* state_stack is a stack of pointers to saved copies of the SET CONSTRAINTS
* state data; each subtransaction level that modifies that state first
* saves a copy, which we use to restore the state if we abort.
*
* events_stack is a stack of copies of the events head/tail pointers,
* which we use to restore those values during subtransaction abort.
*
* depth_stack is a stack of copies of subtransaction-start-time query_depth,
* which we similarly use to clean up at subtransaction abort.
*
* firing_stack is a stack of copies of subtransaction-start-time
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* firing_counter. We use this to recognize which deferred triggers were
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* fired (or marked for firing) within an aborted subtransaction.
*
* We use GetCurrentTransactionNestLevel() to determine the correct array
* index in these stacks. maxtransdepth is the number of allocated entries in
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* each stack. (By not keeping our own stack pointer, we can avoid trouble
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* in cases where errors during subxact abort cause multiple invocations
* of AfterTriggerEndSubXact() at the same nesting depth.)
*/
typedef struct AfterTriggersData
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CommandId firing_counter; /* next firing ID to assign */
SetConstraintState state; /* the active S C state */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerEventList events; /* deferred-event list */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
int query_depth; /* current query list index */
AfterTriggerEventList *query_stack; /* events pending from each query */
int maxquerydepth; /* allocated len of above array */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
MemoryContext event_cxt; /* memory context for events, if any */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* these fields are just for resetting at subtrans abort: */
SetConstraintState *state_stack; /* stacked S C states */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
AfterTriggerEventList *events_stack; /* stacked list pointers */
int *depth_stack; /* stacked query_depths */
CommandId *firing_stack; /* stacked firing_counters */
int maxtransdepth; /* allocated len of above arrays */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
} AfterTriggersData;
typedef AfterTriggersData *AfterTriggers;
static AfterTriggers afterTriggers;
static void AfterTriggerExecute(AfterTriggerEvent event,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Relation rel, TriggerDesc *trigdesc,
FmgrInfo *finfo,
Instrumentation *instr,
MemoryContext per_tuple_context);
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
static SetConstraintState SetConstraintStateCreate(int numalloc);
static SetConstraintState SetConstraintStateCopy(SetConstraintState state);
static SetConstraintState SetConstraintStateAddItem(SetConstraintState state,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Oid tgoid, bool tgisdeferred);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* afterTriggerCheckState()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Returns true if the trigger event is actually in state DEFERRED.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
static bool
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
afterTriggerCheckState(AfterTriggerShared evtshared)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
Oid tgoid = evtshared->ats_tgoid;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
SetConstraintState state = afterTriggers->state;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int i;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
* For not-deferrable triggers (i.e. normal AFTER ROW triggers and
* constraints declared NOT DEFERRABLE), the state is always false.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if ((evtshared->ats_event & AFTER_TRIGGER_DEFERRABLE) == 0)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
return false;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
* Check if SET CONSTRAINTS has been executed for this specific trigger.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
for (i = 0; i < state->numstates; i++)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (state->trigstates[i].sct_tgoid == tgoid)
return state->trigstates[i].sct_tgisdeferred;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
* Check if SET CONSTRAINTS ALL has been executed; if so use that.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
if (state->all_isset)
return state->all_isdeferred;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
* Otherwise return the default state for the trigger.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
return ((evtshared->ats_event & AFTER_TRIGGER_INITDEFERRED) != 0);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* afterTriggerAddEvent()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Add a new trigger event to the specified queue.
* The passed-in event data is copied.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
Make number of args to a function configurable.
2000-01-10 18:14:46 +01:00
static void
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
afterTriggerAddEvent(AfterTriggerEventList *events,
AfterTriggerEvent event, AfterTriggerShared evtshared)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
Size eventsize = SizeofTriggerEvent(event);
Size needed = eventsize + sizeof(AfterTriggerSharedData);
AfterTriggerEventChunk *chunk;
AfterTriggerShared newshared;
AfterTriggerEvent newevent;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* If empty list or not enough room in the tail chunk, make a new chunk.
* We assume here that a new shared record will always be needed.
*/
chunk = events->tail;
if (chunk == NULL ||
chunk->endfree - chunk->freeptr < needed)
{
Size chunksize;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* Create event context if we didn't already */
if (afterTriggers->event_cxt == NULL)
afterTriggers->event_cxt =
AllocSetContextCreate(TopTransactionContext,
"AfterTriggerEvents",
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* Chunk size starts at 1KB and is allowed to increase up to 1MB.
* These numbers are fairly arbitrary, though there is a hard limit at
* AFTER_TRIGGER_OFFSET; else we couldn't link event records to their
* shared records using the available space in ate_flags. Another
* constraint is that if the chunk size gets too huge, the search loop
* below would get slow given a (not too common) usage pattern with
* many distinct event types in a chunk. Therefore, we double the
* preceding chunk size only if there weren't too many shared records
* in the preceding chunk; otherwise we halve it. This gives us some
* ability to adapt to the actual usage pattern of the current query
* while still having large chunk sizes in typical usage. All chunk
* sizes used should be MAXALIGN multiples, to ensure that the shared
* records will be aligned safely.
*/
#define MIN_CHUNK_SIZE 1024
#define MAX_CHUNK_SIZE (1024*1024)
#if MAX_CHUNK_SIZE > (AFTER_TRIGGER_OFFSET+1)
#error MAX_CHUNK_SIZE must not exceed AFTER_TRIGGER_OFFSET
#endif
if (chunk == NULL)
chunksize = MIN_CHUNK_SIZE;
else
{
/* preceding chunk size... */
chunksize = chunk->endptr - (char *) chunk;
/* check number of shared records in preceding chunk */
if ((chunk->endptr - chunk->endfree) <=
(100 * sizeof(AfterTriggerSharedData)))
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
chunksize *= 2; /* okay, double it */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
else
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
chunksize /= 2; /* too many shared records */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
chunksize = Min(chunksize, MAX_CHUNK_SIZE);
}
chunk = MemoryContextAlloc(afterTriggers->event_cxt, chunksize);
chunk->next = NULL;
chunk->freeptr = CHUNK_DATA_START(chunk);
chunk->endptr = chunk->endfree = (char *) chunk + chunksize;
Assert(chunk->endfree - chunk->freeptr >= needed);
if (events->head == NULL)
events->head = chunk;
else
events->tail->next = chunk;
events->tail = chunk;
}
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Try to locate a matching shared-data record already in the chunk. If
* none, make a new one.
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
*/
for (newshared = ((AfterTriggerShared) chunk->endptr) - 1;
(char *) newshared >= chunk->endfree;
newshared--)
{
if (newshared->ats_tgoid == evtshared->ats_tgoid &&
newshared->ats_relid == evtshared->ats_relid &&
newshared->ats_event == evtshared->ats_event &&
newshared->ats_firing_id == 0)
break;
}
if ((char *) newshared < chunk->endfree)
Avoid O(N^2) behavior in deferredTriggerAddEvent() for large numbers of tuples inserted/deleted/updated in a single transaction. On my machine, this reduced the time to delete 80000 tuples in a foreign-key-referencing table from ~15min to ~8sec.
2001-03-13 00:02:00 +01:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
*newshared = *evtshared;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
newshared->ats_firing_id = 0; /* just to be sure */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
chunk->endfree = (char *) newshared;
}
/* Insert the data */
newevent = (AfterTriggerEvent) chunk->freeptr;
memcpy(newevent, event, eventsize);
/* ... and link the new event to its shared record */
newevent->ate_flags &= ~AFTER_TRIGGER_OFFSET;
newevent->ate_flags |= (char *) newshared - (char *) newevent;
chunk->freeptr += eventsize;
events->tailfree = chunk->freeptr;
}
/* ----------
* afterTriggerFreeEventList()
*
* Free all the event storage in the given list.
* ----------
*/
static void
afterTriggerFreeEventList(AfterTriggerEventList *events)
{
AfterTriggerEventChunk *chunk;
AfterTriggerEventChunk *next_chunk;
for (chunk = events->head; chunk != NULL; chunk = next_chunk)
{
next_chunk = chunk->next;
pfree(chunk);
}
events->head = NULL;
events->tail = NULL;
events->tailfree = NULL;
}
/* ----------
* afterTriggerRestoreEventList()
*
* Restore an event list to its prior length, removing all the events
* added since it had the value old_events.
* ----------
*/
static void
afterTriggerRestoreEventList(AfterTriggerEventList *events,
const AfterTriggerEventList *old_events)
{
AfterTriggerEventChunk *chunk;
AfterTriggerEventChunk *next_chunk;
if (old_events->tail == NULL)
{
/* restoring to a completely empty state, so free everything */
afterTriggerFreeEventList(events);
Avoid O(N^2) behavior in deferredTriggerAddEvent() for large numbers of tuples inserted/deleted/updated in a single transaction. On my machine, this reduced the time to delete 80000 tuples in a foreign-key-referencing table from ~15min to ~8sec.
2001-03-13 00:02:00 +01:00
}
else
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
*events = *old_events;
/* free any chunks after the last one we want to keep */
for (chunk = events->tail->next; chunk != NULL; chunk = next_chunk)
{
next_chunk = chunk->next;
pfree(chunk);
}
/* and clean up the tail chunk to be the right length */
events->tail->next = NULL;
events->tail->freeptr = events->tailfree;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* We don't make any effort to remove now-unused shared data records.
* They might still be useful, anyway.
*/
Avoid O(N^2) behavior in deferredTriggerAddEvent() for large numbers of tuples inserted/deleted/updated in a single transaction. On my machine, this reduced the time to delete 80000 tuples in a foreign-key-referencing table from ~15min to ~8sec.
2001-03-13 00:02:00 +01:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerExecute()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
* Fetch the required tuples back from the heap and fire one
* single trigger function.
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
*
* Frequently, this will be fired many times in a row for triggers of
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* a single relation. Therefore, we cache the open relation and provide
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
* fmgr lookup cache space at the caller level. (For triggers fired at
* the end of a query, we can even piggyback on the executor's state.)
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
*
* event: event currently being fired.
* rel: open relation for event.
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
* trigdesc: working copy of rel's trigger info.
* finfo: array of fmgr lookup cache entries (one per trigger in trigdesc).
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
* instr: array of EXPLAIN ANALYZE instrumentation nodes (one per trigger),
* or NULL if no instrumentation is wanted.
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
* per_tuple_context: memory context to call trigger function in.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
static void
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerExecute(AfterTriggerEvent event,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
Relation rel, TriggerDesc *trigdesc,
FmgrInfo *finfo, Instrumentation *instr,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
MemoryContext per_tuple_context)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerShared evtshared = GetTriggerSharedData(event);
Oid tgoid = evtshared->ats_tgoid;
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
TriggerData LocTriggerData;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
HeapTupleData tuple1;
HeapTupleData tuple2;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
HeapTuple rettuple;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
Buffer buffer1 = InvalidBuffer;
Buffer buffer2 = InvalidBuffer;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
int tgindx;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
/*
* Locate trigger in trigdesc.
*/
LocTriggerData.tg_trigger = NULL;
for (tgindx = 0; tgindx < trigdesc->numtriggers; tgindx++)
{
if (trigdesc->triggers[tgindx].tgoid == tgoid)
{
LocTriggerData.tg_trigger = &(trigdesc->triggers[tgindx]);
break;
}
}
if (LocTriggerData.tg_trigger == NULL)
elog(ERROR, "could not find trigger %u", tgoid);
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If doing EXPLAIN ANALYZE, start charging time to this trigger. We want
* to include time spent re-fetching tuples in the trigger cost.
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
*/
if (instr)
InstrStartNode(instr + tgindx);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Fetch the required tuple(s).
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (ItemPointerIsValid(&(event->ate_ctid1)))
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
ItemPointerCopy(&(event->ate_ctid1), &(tuple1.t_self));
if (!heap_fetch(rel, SnapshotAny, &tuple1, &buffer1, false, NULL))
elog(ERROR, "failed to fetch tuple1 for AFTER trigger");
LocTriggerData.tg_trigtuple = &tuple1;
LocTriggerData.tg_trigtuplebuf = buffer1;
}
else
{
LocTriggerData.tg_trigtuple = NULL;
LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* don't touch ctid2 if not there */
if ((event->ate_flags & AFTER_TRIGGER_2CTIDS) &&
ItemPointerIsValid(&(event->ate_ctid2)))
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
ItemPointerCopy(&(event->ate_ctid2), &(tuple2.t_self));
if (!heap_fetch(rel, SnapshotAny, &tuple2, &buffer2, false, NULL))
elog(ERROR, "failed to fetch tuple2 for AFTER trigger");
LocTriggerData.tg_newtuple = &tuple2;
LocTriggerData.tg_newtuplebuf = buffer2;
}
else
{
LocTriggerData.tg_newtuple = NULL;
LocTriggerData.tg_newtuplebuf = InvalidBuffer;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Fix AfterTriggerExecute() to pass tg_trigtuple and tg_newtuple as NULLs rather than pointers to garbage, when calling AFTER STATEMENT triggers. Michael Fuhr
2006-08-03 18:04:41 +02:00
* Setup the remaining trigger information
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.type = T_TriggerData;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
LocTriggerData.tg_event =
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
evtshared->ats_event & (TRIGGER_EVENT_OPMASK | TRIGGER_EVENT_ROW);
Second round of fmgr changes: triggers are now invoked in new style, CurrentTriggerData is history.
2000-05-29 03:59:17 +02:00
LocTriggerData.tg_relation = rel;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
MemoryContextReset(per_tuple_context);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Call the trigger and throw away any possibly returned updated tuple.
* (Don't let ExecCallTriggerFunc measure EXPLAIN time.)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
rettuple = ExecCallTriggerFunc(&LocTriggerData,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
tgindx,
finfo,
NULL,
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
per_tuple_context);
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (rettuple != NULL && rettuple != &tuple1 && rettuple != &tuple2)
Some changes to prepare for LONG attributes. Jan
1999-12-16 23:20:03 +01:00
heap_freetuple(rettuple);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
* Release buffers
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (buffer1 != InvalidBuffer)
ReleaseBuffer(buffer1);
if (buffer2 != InvalidBuffer)
ReleaseBuffer(buffer2);
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If doing EXPLAIN ANALYZE, stop charging time to this trigger, and count
* one "tuple returned" (really the number of firings).
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
*/
if (instr)
Make EXPLAIN sampling smarter, to avoid excessive sampling delay. Martijn van Oosterhout
2006-05-30 16:01:58 +02:00
InstrStopNode(instr + tgindx, 1);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
* afterTriggerMarkEvents()
*
* Scan the given event list for not yet invoked events. Mark the ones
* that can be invoked now with the current firing ID.
*
* If move_list isn't NULL, events that are not to be invoked now are
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* transferred to move_list.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*
* When immediate_only is TRUE, do not invoke currently-deferred triggers.
* (This will be FALSE only at main transaction exit.)
*
* Returns TRUE if any invokable events were found.
*/
static bool
afterTriggerMarkEvents(AfterTriggerEventList *events,
AfterTriggerEventList *move_list,
bool immediate_only)
{
bool found = false;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEvent event;
AfterTriggerEventChunk *chunk;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for_each_event_chunk(event, chunk, *events)
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerShared evtshared = GetTriggerSharedData(event);
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
bool defer_it = false;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (!(event->ate_flags &
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
(AFTER_TRIGGER_DONE | AFTER_TRIGGER_IN_PROGRESS)))
{
/*
* This trigger hasn't been called or scheduled yet. Check if we
* should call it now.
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (immediate_only && afterTriggerCheckState(evtshared))
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
defer_it = true;
}
else
{
/*
* Mark it as to be fired in this firing cycle.
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
evtshared->ats_firing_id = afterTriggers->firing_counter;
event->ate_flags |= AFTER_TRIGGER_IN_PROGRESS;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
found = true;
}
}
/*
* If it's deferred, move it to move_list, if requested.
*/
if (defer_it && move_list != NULL)
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* add it to move_list */
afterTriggerAddEvent(move_list, event, evtshared);
/* mark original copy "done" so we don't do it again */
event->ate_flags |= AFTER_TRIGGER_DONE;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
}
}
return found;
}
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* afterTriggerInvokeEvents()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Scan the given event list for events that are marked as to be fired
* in the current firing cycle, and fire them.
*
Arrange to cache a ResultRelInfo in the executor's EState for relations that are not one of the query's defined result relations, but nonetheless have triggers fired against them while the query is active. This was formerly impossible but can now occur because of my recent patch to fix the firing order for RI triggers. Caching a ResultRelInfo avoids duplicating work by repeatedly opening and closing the same relation, and also allows EXPLAIN ANALYZE to "see" and report on these extra triggers. Use the same mechanism to cache open relations when firing deferred triggers at transaction shutdown; this replaces the former one-element-cache strategy used in that case, and should improve performance a bit when there are deferred triggers on a number of relations.
2007-08-15 23:39:50 +02:00
* If estate isn't NULL, we use its result relation info to avoid repeated
* openings and closing of trigger target relations. If it is NULL, we
* make one locally to cache the info in case there are multiple trigger
* events per rel.
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* When delete_ok is TRUE, it's safe to delete fully-processed events.
* (We are not very tense about that: we simply reset a chunk to be empty
* if all its events got fired. The objective here is just to avoid useless
* rescanning of events when a trigger queues new events during transaction
* end, so it's not necessary to worry much about the case where only
* some events are fired.)
*
* Returns TRUE if no unfired events remain in the list (this allows us
* to avoid repeating afterTriggerMarkEvents).
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
static bool
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggerInvokeEvents(AfterTriggerEventList *events,
CommandId firing_id,
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
EState *estate,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
bool delete_ok)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
bool all_fired = true;
AfterTriggerEventChunk *chunk;
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
MemoryContext per_tuple_context;
Arrange to cache a ResultRelInfo in the executor's EState for relations that are not one of the query's defined result relations, but nonetheless have triggers fired against them while the query is active. This was formerly impossible but can now occur because of my recent patch to fix the firing order for RI triggers. Caching a ResultRelInfo avoids duplicating work by repeatedly opening and closing the same relation, and also allows EXPLAIN ANALYZE to "see" and report on these extra triggers. Use the same mechanism to cache open relations when firing deferred triggers at transaction shutdown; this replaces the former one-element-cache strategy used in that case, and should improve performance a bit when there are deferred triggers on a number of relations.
2007-08-15 23:39:50 +02:00
bool local_estate = false;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
Relation rel = NULL;
Arrange to copy relcache's trigdesc structure at the start of any query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
2002-10-14 18:51:30 +02:00
TriggerDesc *trigdesc = NULL;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
FmgrInfo *finfo = NULL;
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
Instrumentation *instr = NULL;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Arrange to cache a ResultRelInfo in the executor's EState for relations that are not one of the query's defined result relations, but nonetheless have triggers fired against them while the query is active. This was formerly impossible but can now occur because of my recent patch to fix the firing order for RI triggers. Caching a ResultRelInfo avoids duplicating work by repeatedly opening and closing the same relation, and also allows EXPLAIN ANALYZE to "see" and report on these extra triggers. Use the same mechanism to cache open relations when firing deferred triggers at transaction shutdown; this replaces the former one-element-cache strategy used in that case, and should improve performance a bit when there are deferred triggers on a number of relations.
2007-08-15 23:39:50 +02:00
/* Make a local EState if need be */
if (estate == NULL)
{
estate = CreateExecutorState();
local_estate = true;
}
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
/* Make a per-tuple memory context for trigger function calls */
per_tuple_context =
AllocSetContextCreate(CurrentMemoryContext,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
"AfterTriggerTupleContext",
Fix some poor decisions about sizing of trigger-related memory contexts.
2001-08-02 17:59:28 +02:00
ALLOCSET_DEFAULT_MINSIZE,
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for_each_chunk(chunk, *events)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEvent event;
bool all_fired_in_chunk = true;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for_each_event(event, chunk)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerShared evtshared = GetTriggerSharedData(event);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Is it one for me to fire?
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if ((event->ate_flags & AFTER_TRIGGER_IN_PROGRESS) &&
evtshared->ats_firing_id == firing_id)
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* So let's fire it... but first, find the correct relation if
* this is not the same relation as before.
*/
if (rel == NULL || RelationGetRelid(rel) != evtshared->ats_relid)
{
ResultRelInfo *rInfo;
rInfo = ExecGetTriggerResultRel(estate, evtshared->ats_relid);
rel = rInfo->ri_RelationDesc;
trigdesc = rInfo->ri_TrigDesc;
finfo = rInfo->ri_TrigFunctions;
instr = rInfo->ri_TrigInstrument;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
if (trigdesc == NULL) /* should not happen */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
elog(ERROR, "relation %u has no triggers",
evtshared->ats_relid);
}
Remove 'triggered data change violation' error check, per recent discussions in pghackers.
2001-11-16 17:31:16 +01:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* Fire it. Note that the AFTER_TRIGGER_IN_PROGRESS flag is
* still set, so recursive examinations of the event list
* won't try to re-fire it.
*/
AfterTriggerExecute(event, rel, trigdesc, finfo, instr,
per_tuple_context);
Remove 'triggered data change violation' error check, per recent discussions in pghackers.
2001-11-16 17:31:16 +01:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* Mark the event as done.
*/
event->ate_flags &= ~AFTER_TRIGGER_IN_PROGRESS;
event->ate_flags |= AFTER_TRIGGER_DONE;
}
else if (!(event->ate_flags & AFTER_TRIGGER_DONE))
{
/* something remains to be done */
all_fired = all_fired_in_chunk = false;
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* Clear the chunk if delete_ok and nothing left of interest */
if (delete_ok && all_fired_in_chunk)
Remove 'triggered data change violation' error check, per recent discussions in pghackers.
2001-11-16 17:31:16 +01:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
chunk->freeptr = CHUNK_DATA_START(chunk);
chunk->endfree = chunk->endptr;
Remove 'triggered data change violation' error check, per recent discussions in pghackers.
2001-11-16 17:31:16 +01:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Clean up per-tuple memory leaks in trigger firing and plpgsql expression evaluation.
2001-01-22 01:50:07 +01:00
Remove 'triggered data change violation' error check, per recent discussions in pghackers.
2001-11-16 17:31:16 +01:00
/* Release working resources */
Arrange to cache a ResultRelInfo in the executor's EState for relations that are not one of the query's defined result relations, but nonetheless have triggers fired against them while the query is active. This was formerly impossible but can now occur because of my recent patch to fix the firing order for RI triggers. Caching a ResultRelInfo avoids duplicating work by repeatedly opening and closing the same relation, and also allows EXPLAIN ANALYZE to "see" and report on these extra triggers. Use the same mechanism to cache open relations when firing deferred triggers at transaction shutdown; this replaces the former one-element-cache strategy used in that case, and should improve performance a bit when there are deferred triggers on a number of relations.
2007-08-15 23:39:50 +02:00
MemoryContextDelete(per_tuple_context);
if (local_estate)
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
{
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
ListCell *l;
Arrange to cache a ResultRelInfo in the executor's EState for relations that are not one of the query's defined result relations, but nonetheless have triggers fired against them while the query is active. This was formerly impossible but can now occur because of my recent patch to fix the firing order for RI triggers. Caching a ResultRelInfo avoids duplicating work by repeatedly opening and closing the same relation, and also allows EXPLAIN ANALYZE to "see" and report on these extra triggers. Use the same mechanism to cache open relations when firing deferred triggers at transaction shutdown; this replaces the former one-element-cache strategy used in that case, and should improve performance a bit when there are deferred triggers on a number of relations.
2007-08-15 23:39:50 +02:00
foreach(l, estate->es_trig_target_relations)
{
ResultRelInfo *resultRelInfo = (ResultRelInfo *) lfirst(l);
/* Close indices and then the relation itself */
ExecCloseIndices(resultRelInfo);
heap_close(resultRelInfo->ri_RelationDesc, NoLock);
}
FreeExecutorState(estate);
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
}
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
return all_fired;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerBeginXact()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
* Called at transaction start (either BEGIN or implicit for single
* statement outside of transaction block).
* ----------
*/
void
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerBeginXact(void)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Assert(afterTriggers == NULL);
/*
* Build empty after-trigger state structure
*/
afterTriggers = (AfterTriggers)
MemoryContextAlloc(TopTransactionContext,
sizeof(AfterTriggersData));
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
afterTriggers->firing_counter = (CommandId) 1; /* mustn't be 0 */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state = SetConstraintStateCreate(8);
afterTriggers->events.head = NULL;
afterTriggers->events.tail = NULL;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
afterTriggers->events.tailfree = NULL;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->query_depth = -1;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* We initialize the query stack to a reasonable size */
afterTriggers->query_stack = (AfterTriggerEventList *)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
MemoryContextAlloc(TopTransactionContext,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
8 * sizeof(AfterTriggerEventList));
afterTriggers->maxquerydepth = 8;
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
/* Context for events is created only when needed */
afterTriggers->event_cxt = NULL;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* Subtransaction stack is empty until/unless needed */
afterTriggers->state_stack = NULL;
afterTriggers->events_stack = NULL;
afterTriggers->depth_stack = NULL;
afterTriggers->firing_stack = NULL;
afterTriggers->maxtransdepth = 0;
}
/* ----------
* AfterTriggerBeginQuery()
*
* Called just before we start processing a single query within a
* transaction (or subtransaction). Set up to record AFTER trigger
* events queued by the query. Note that it is allowed to have
* nested queries within a (sub)transaction.
* ----------
*/
void
AfterTriggerBeginQuery(void)
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEventList *events;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* Must be inside a transaction */
Assert(afterTriggers != NULL);
/* Increase the query stack depth */
afterTriggers->query_depth++;
pgindent run.
2003-08-04 02:43:34 +02:00
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Allocate more space in the query stack if needed.
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (afterTriggers->query_depth >= afterTriggers->maxquerydepth)
{
/* repalloc will keep the stack in the same context */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
int new_alloc = afterTriggers->maxquerydepth * 2;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->query_stack = (AfterTriggerEventList *)
repalloc(afterTriggers->query_stack,
new_alloc * sizeof(AfterTriggerEventList));
afterTriggers->maxquerydepth = new_alloc;
}
/* Initialize this query's list to empty */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
events = &afterTriggers->query_stack[afterTriggers->query_depth];
events->head = NULL;
events->tail = NULL;
events->tailfree = NULL;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerEndQuery()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Called after one query has been completely processed. At this time
* we invoke all AFTER IMMEDIATE trigger events queued by the query, and
* transfer deferred trigger events to the global deferred-trigger list.
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
*
* Note that this should be called just BEFORE closing down the executor
* with ExecutorEnd, because we make use of the EState's info about
* target relations.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
void
Improve EXPLAIN ANALYZE to show the time spent in each trigger when executing a statement that fires triggers. Formerly this time was included in "Total runtime" but not otherwise accounted for. As a side benefit, we avoid re-opening relations when firing non-deferred AFTER triggers, because the trigger code can re-use the main executor's ResultRelInfo data structure.
2005-03-25 22:58:00 +01:00
AfterTriggerEndQuery(EState *estate)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerEventList *events;
/* Must be inside a transaction */
Assert(afterTriggers != NULL);
/* Must be inside a query, too */
Assert(afterTriggers->query_depth >= 0);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Process all immediate-mode triggers queued by the query, and move the
* deferred ones to the main list of deferred events.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* Notice that we decide which ones will be fired, and put the deferred
* ones on the main list, before anything is actually fired. This ensures
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* reasonably sane behavior if a trigger function does SET CONSTRAINTS ...
* IMMEDIATE: all events we have decided to defer will be available for it
* to fire.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* We loop in case a trigger queues more events at the same query level
* (is that even possible?). Be careful here: firing a trigger could
* result in query_stack being repalloc'd, so we can't save its address
* across afterTriggerInvokeEvents calls.
Repair problems occurring when multiple RI updates have to be done to the same row within one query: we were firing check triggers before all the updates were done, leading to bogus failures. Fix by making the triggers queued by an RI update go at the end of the outer query's trigger event list, thereby effectively making the processing "breadth-first". This was indeed how it worked pre-8.0, so the bug does not occur in the 7.x branches. Per report from Pavel Stehule.
2007-08-15 21:15:47 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* If we find no firable events, we don't have to increment
* firing_counter.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for (;;)
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
events = &afterTriggers->query_stack[afterTriggers->query_depth];
if (afterTriggerMarkEvents(events, &afterTriggers->events, true))
{
CommandId firing_id = afterTriggers->firing_counter++;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* OK to delete the immediate events after processing them */
if (afterTriggerInvokeEvents(events, firing_id, estate, true))
break; /* all fired */
}
else
break;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/* Release query-local storage for events */
afterTriggerFreeEventList(&afterTriggers->query_stack[afterTriggers->query_depth]);
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->query_depth--;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
/* ----------
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
* AfterTriggerFireDeferred()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
* Called just before the current transaction is committed. At this
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
* time we invoke all pending DEFERRED triggers.
*
* It is possible for other modules to queue additional deferred triggers
* during pre-commit processing; therefore xact.c may have to call this
* multiple times.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
void
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
AfterTriggerFireDeferred(void)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerEventList *events;
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
bool snap_pushed = false;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/* Must be inside a transaction */
Assert(afterTriggers != NULL);
/* ... but not inside a query */
Assert(afterTriggers->query_depth == -1);
ActiveSnapshot must be set to something valid while running deferred triggers during COMMIT. Per trouble report from Frank van Vugt.
2004-12-07 00:57:17 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If there are any triggers to fire, make sure we have set a snapshot for
* them to use. (Since PortalRunUtility doesn't set a snap for COMMIT, we
* can't assume ActiveSnapshot is valid on entry.)
ActiveSnapshot must be set to something valid while running deferred triggers during COMMIT. Per trouble report from Frank van Vugt.
2004-12-07 00:57:17 +01:00
*/
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
events = &afterTriggers->events;
if (events->head != NULL)
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
{
PushActiveSnapshot(GetTransactionSnapshot());
snap_pushed = true;
}
ActiveSnapshot must be set to something valid while running deferred triggers during COMMIT. Per trouble report from Frank van Vugt.
2004-12-07 00:57:17 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* Run all the remaining triggers. Loop until they are all gone, in case
* some trigger queues more for us to do.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
while (afterTriggerMarkEvents(events, NULL, false))
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CommandId firing_id = afterTriggers->firing_counter++;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (afterTriggerInvokeEvents(events, firing_id, NULL, true))
break; /* all fired */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
/*
* We don't bother freeing the event list, since it will go away anyway
* (and more efficiently than via pfree) in AfterTriggerEndXact.
*/
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
if (snap_pushed)
PopActiveSnapshot();
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
/* ----------
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
* AfterTriggerEndXact()
*
* The current transaction is finishing.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
* Any unfired triggers are canceled so we simply throw
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* away anything we know.
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
*
* Note: it is possible for this to be called repeatedly in case of
* error during transaction abort; therefore, do not complain if
* already closed down.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
void
Fix interaction between materializing holdable cursors and firing deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
2005-04-11 21:51:16 +02:00
AfterTriggerEndXact(bool isCommit)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
In an attempt to simplify my life I'm submitting this patch that restructures the deferred trigger queue. The fundamental change is to put all the static variables to hold the deferred triggers in a single structure. Alvaro Herrera
2003-06-25 01:25:44 +02:00
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Forget everything we know about AFTER triggers.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* Since all the info is in TopTransactionContext or children thereof, we
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
* don't really need to do anything to reclaim memory. However, the
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* pending-events list could be large, and so it's useful to discard it as
* soon as possible --- especially if we are aborting because we ran out
* of memory for the list!
In an attempt to simplify my life I'm submitting this patch that restructures the deferred trigger queue. The fundamental change is to put all the static variables to hold the deferred triggers in a single structure. Alvaro Herrera
2003-06-25 01:25:44 +02:00
*/
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
if (afterTriggers && afterTriggers->event_cxt)
MemoryContextDelete(afterTriggers->event_cxt);
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers = NULL;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerBeginSubXact()
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*
* Start a subtransaction.
*/
void
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerBeginSubXact(void)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
int my_level = GetCurrentTransactionNestLevel();
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Ignore call if the transaction is in aborted state. (Probably
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* shouldn't happen?)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (afterTriggers == NULL)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
return;
/*
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
* Allocate more space in the stacks if needed. (Note: because the
Fix pgindent to properly handle 'else' and single-line comments on the same line; previous fix was only partial. Re-run pgindent on files that need it.
2007-11-16 00:23:44 +01:00
* minimum nest level of a subtransaction is 2, we waste the first couple
* entries of each array; not worth the notational effort to avoid it.)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
while (my_level >= afterTriggers->maxtransdepth)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (afterTriggers->maxtransdepth == 0)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
MemoryContext old_cxt;
old_cxt = MemoryContextSwitchTo(TopTransactionContext);
#define DEFTRIG_INITALLOC 8
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack = (SetConstraintState *)
palloc(DEFTRIG_INITALLOC * sizeof(SetConstraintState));
afterTriggers->events_stack = (AfterTriggerEventList *)
palloc(DEFTRIG_INITALLOC * sizeof(AfterTriggerEventList));
afterTriggers->depth_stack = (int *)
palloc(DEFTRIG_INITALLOC * sizeof(int));
afterTriggers->firing_stack = (CommandId *)
palloc(DEFTRIG_INITALLOC * sizeof(CommandId));
afterTriggers->maxtransdepth = DEFTRIG_INITALLOC;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
MemoryContextSwitchTo(old_cxt);
}
else
{
/* repalloc will keep the stacks in the same context */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
int new_alloc = afterTriggers->maxtransdepth * 2;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack = (SetConstraintState *)
repalloc(afterTriggers->state_stack,
new_alloc * sizeof(SetConstraintState));
afterTriggers->events_stack = (AfterTriggerEventList *)
repalloc(afterTriggers->events_stack,
new_alloc * sizeof(AfterTriggerEventList));
afterTriggers->depth_stack = (int *)
repalloc(afterTriggers->depth_stack,
new_alloc * sizeof(int));
afterTriggers->firing_stack = (CommandId *)
repalloc(afterTriggers->firing_stack,
new_alloc * sizeof(CommandId));
afterTriggers->maxtransdepth = new_alloc;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Push the current information into the stack. The SET CONSTRAINTS state
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
* is not saved until/unless changed. Likewise, we don't make a
* per-subtransaction event context until needed.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack[my_level] = NULL;
afterTriggers->events_stack[my_level] = afterTriggers->events;
afterTriggers->depth_stack[my_level] = afterTriggers->query_depth;
afterTriggers->firing_stack[my_level] = afterTriggers->firing_counter;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerEndSubXact()
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*
* The current subtransaction is ending.
*/
void
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerEndSubXact(bool isCommit)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
int my_level = GetCurrentTransactionNestLevel();
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
SetConstraintState state;
AfterTriggerEvent event;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEventChunk *chunk;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
CommandId subxact_firing_id;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Ignore call if the transaction is in aborted state. (Probably
* unneeded)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (afterTriggers == NULL)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
return;
/*
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
* Pop the prior state if needed.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
if (isCommit)
{
Fix assorted core dumps and Assert failures that could occur during AbortTransaction or AbortSubTransaction, when trying to clean up after an error that prevented (sub)transaction start from completing: * access to TopTransactionResourceOwner that might not exist * assert failure in AtEOXact_GUC, if AtStart_GUC not called yet * assert failure or core dump in AfterTriggerEndSubXact, if AfterTriggerBeginSubXact not called yet Per testing by injecting elog(ERROR) at successive steps in StartTransaction and StartSubTransaction. It's not clear whether all of these cases could really occur in the field, but at least one of them is easily exposed by simple stress testing, as per my accidental discovery yesterday.
2010-01-24 22:49:17 +01:00
Assert(my_level < afterTriggers->maxtransdepth);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/* If we saved a prior state, we don't need it anymore */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state = afterTriggers->state_stack[my_level];
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
if (state != NULL)
pfree(state);
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
/* this avoids double pfree if error later: */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack[my_level] = NULL;
Assert(afterTriggers->query_depth ==
afterTriggers->depth_stack[my_level]);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
else
{
/*
Fix assorted core dumps and Assert failures that could occur during AbortTransaction or AbortSubTransaction, when trying to clean up after an error that prevented (sub)transaction start from completing: * access to TopTransactionResourceOwner that might not exist * assert failure in AtEOXact_GUC, if AtStart_GUC not called yet * assert failure or core dump in AfterTriggerEndSubXact, if AfterTriggerBeginSubXact not called yet Per testing by injecting elog(ERROR) at successive steps in StartTransaction and StartSubTransaction. It's not clear whether all of these cases could really occur in the field, but at least one of them is easily exposed by simple stress testing, as per my accidental discovery yesterday.
2010-01-24 22:49:17 +01:00
* Aborting. It is possible subxact start failed before calling
* AfterTriggerBeginSubXact, in which case we mustn't risk touching
* stack levels that aren't there.
*/
if (my_level >= afterTriggers->maxtransdepth)
return;
/*
* Release any event lists from queries being aborted, and restore
* query_depth to its pre-subxact value.
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
while (afterTriggers->query_depth > afterTriggers->depth_stack[my_level])
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
afterTriggerFreeEventList(&afterTriggers->query_stack[afterTriggers->query_depth]);
afterTriggers->query_depth--;
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
}
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
Assert(afterTriggers->query_depth ==
afterTriggers->depth_stack[my_level]);
Several changes to reduce the probability of running out of memory during AbortTransaction, which would lead to recursion and eventual PANIC exit as illustrated in recent report from Jeff Davis. First, in xact.c create a special dedicated memory context for AbortTransaction to run in. This solves the problem as long as AbortTransaction doesn't need more than 32K (or whatever other size we create the context with). But in corner cases it might. Second, in trigger.c arrange to keep pending after-trigger event records in separate contexts that can be freed near the beginning of AbortTransaction, rather than having them persist until CleanupTransaction as before. Third, in portalmem.c arrange to free executor state data earlier as well. These two changes should result in backing off the out-of-memory condition before AbortTransaction needs any significant amount of memory, at least in typical cases such as memory overrun due to too many trigger events or too big an executor hash table. And all the same for subtransaction abort too, of course.
2006-11-23 02:14:59 +01:00
/*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Restore the global deferred-event list to its former length,
* discarding any events queued by the subxact.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
afterTriggerRestoreEventList(&afterTriggers->events,
&afterTriggers->events_stack[my_level]);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Restore the trigger state. If the saved state is NULL, then this
* subxact didn't save it, so it doesn't need restoring.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state = afterTriggers->state_stack[my_level];
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
if (state != NULL)
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
pfree(afterTriggers->state);
afterTriggers->state = state;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
/* this avoids double pfree if error later: */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack[my_level] = NULL;
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Scan for any remaining deferred events that were marked DONE or IN
* PROGRESS by this subxact or a child, and un-mark them. We can
* recognize such events because they have a firing ID greater than or
* equal to the firing_counter value we saved at subtransaction start.
* (This essentially assumes that the current subxact includes all
* subxacts started after it.)
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*/
subxact_firing_id = afterTriggers->firing_stack[my_level];
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for_each_event_chunk(event, chunk, afterTriggers->events)
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerShared evtshared = GetTriggerSharedData(event);
if (event->ate_flags &
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
(AFTER_TRIGGER_DONE | AFTER_TRIGGER_IN_PROGRESS))
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (evtshared->ats_firing_id >= subxact_firing_id)
event->ate_flags &=
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
~(AFTER_TRIGGER_DONE | AFTER_TRIGGER_IN_PROGRESS);
}
}
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
}
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Create an empty SetConstraintState with room for numalloc trigstates
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
static SetConstraintState
SetConstraintStateCreate(int numalloc)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
SetConstraintState state;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/* Behave sanely with numalloc == 0 */
if (numalloc <= 0)
numalloc = 1;
/*
* We assume that zeroing will correctly initialize the state values.
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state = (SetConstraintState)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
MemoryContextAllocZero(TopTransactionContext,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
sizeof(SetConstraintStateData) +
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(numalloc - 1) *sizeof(SetConstraintTriggerData));
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
state->numalloc = numalloc;
return state;
}
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Copy a SetConstraintState
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
static SetConstraintState
SetConstraintStateCopy(SetConstraintState origstate)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
SetConstraintState state;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state = SetConstraintStateCreate(origstate->numstates);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
state->all_isset = origstate->all_isset;
state->all_isdeferred = origstate->all_isdeferred;
state->numstates = origstate->numstates;
memcpy(state->trigstates, origstate->trigstates,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
origstate->numstates * sizeof(SetConstraintTriggerData));
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
return state;
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Add a per-trigger item to a SetConstraintState. Returns possibly-changed
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
* pointer to the state object (it will change if we have to repalloc).
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
static SetConstraintState
SetConstraintStateAddItem(SetConstraintState state,
Oid tgoid, bool tgisdeferred)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
if (state->numstates >= state->numalloc)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int newalloc = state->numalloc * 2;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
newalloc = Max(newalloc, 8); /* in case original has size 0 */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state = (SetConstraintState)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
repalloc(state,
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
sizeof(SetConstraintStateData) +
(newalloc - 1) *sizeof(SetConstraintTriggerData));
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
state->numalloc = newalloc;
Assert(state->numstates < state->numalloc);
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state->trigstates[state->numstates].sct_tgoid = tgoid;
state->trigstates[state->numstates].sct_tgisdeferred = tgisdeferred;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
state->numstates++;
return state;
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerSetState()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Execute the SET CONSTRAINTS ... utility command.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
void
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
AfterTriggerSetState(ConstraintsSetStmt *stmt)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
int my_level = GetCurrentTransactionNestLevel();
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
/*
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* Ignore call if we aren't in a transaction. (Shouldn't happen?)
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (afterTriggers == NULL)
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
return;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If in a subtransaction, and we didn't save the current state already,
* save it so it can be restored if the subtransaction aborts.
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
Fix a number of places where brittle data structures or overly strong Asserts would lead to a server core dump if an error occurred while trying to abort a failed subtransaction (thereby leading to re-execution of whatever parts of AbortSubTransaction had already run). This of course does not prevent such an error from creating an infinite loop, but at least we don't make the situation worse. Responds to an open item on the subtransactions to-do list.
2004-09-07 01:33:48 +02:00
if (my_level > 1 &&
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack[my_level] == NULL)
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state_stack[my_level] =
SetConstraintStateCopy(afterTriggers->state);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* Handle SET CONSTRAINTS ALL ...
*/
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
if (stmt->constraints == NIL)
{
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
/*
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
* Forget any previous SET CONSTRAINTS commands in this transaction.
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state->numstates = 0;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
* Set the per-transaction ALL state to known.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state->all_isset = true;
afterTriggers->state->all_isdeferred = stmt->deferred;
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
}
else
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
Relation conrel;
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
Relation tgrel;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
List *conoidlist = NIL;
List *tgoidlist = NIL;
ListCell *lc;
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
/*
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
* Handle SET CONSTRAINTS constraint-name [, ...]
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
*
* First, identify all the named constraints and make a list of their
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* OIDs. Since, unlike the SQL spec, we allow multiple constraints of
* the same name within a schema, the specifications are not
* necessarily unique. Our strategy is to target all matching
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* constraints within the first search-path schema that has any
* matches, but disregard matches in schemas beyond the first match.
* (This is a bit odd but it's the historical behavior.)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
conrel = heap_open(ConstraintRelationId, AccessShareLock);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
foreach(lc, stmt->constraints)
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
RangeVar *constraint = lfirst(lc);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
bool found;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
List *namespacelist;
ListCell *nslc;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
if (constraint->catalogname)
{
if (strcmp(constraint->catalogname, get_database_name(MyDatabaseId)) != 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cross-database references are not implemented: \"%s.%s.%s\"",
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
constraint->catalogname, constraint->schemaname,
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
constraint->relname)));
}
A bunch of changes aimed at reducing backend startup time... Improve 'pg_internal.init' relcache entry preload mechanism so that it is safe to use for all system catalogs, and arrange to preload a realistic set of system-catalog entries instead of only the three nailed-in-cache indexes that were formerly loaded this way. Fix mechanism for deleting out-of-date pg_internal.init files: this must be synchronized with transaction commit, not just done at random times within transactions. Drive it off relcache invalidation mechanism so that no special-case tests are needed. Cache additional information in relcache entries for indexes (their pg_index tuples and index-operator OIDs) to eliminate repeated lookups. Also cache index opclass info at the per-opclass level to avoid repeated lookups during relcache load. Generalize 'systable scan' utilities originally developed by Hiroshi, move them into genam.c, use in a number of places where there was formerly ugly code for choosing either heap or index scan. In particular this allows simplification of the logic that prevents infinite recursion between syscache and relcache during startup: we can easily switch to heapscans in relcache.c when and where needed to avoid recursion, so IndexScanOK becomes simpler and does not need any expensive initialization. Eliminate useless opening of a heapscan data structure while doing an indexscan (this saves an mdnblocks call and thus at least one kernel call).
2002-02-19 21:11:20 +01:00
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
/*
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
* If we're given the schema name with the constraint, look only
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* in that schema. If given a bare constraint name, use the
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
* search path to find the first matching constraint.
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
*/
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
if (constraint->schemaname)
{
Oid namespaceId = LookupExplicitNamespace(constraint->schemaname);
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
namespacelist = list_make1_oid(namespaceId);
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
}
else
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
namespacelist = fetch_search_path(true);
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
found = false;
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
foreach(nslc, namespacelist)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
Oid namespaceId = lfirst_oid(nslc);
SysScanDesc conscan;
ScanKeyData skey[2];
HeapTuple tup;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
ScanKeyInit(&skey[0],
Anum_pg_constraint_conname,
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
BTEqualStrategyNumber, F_NAMEEQ,
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
CStringGetDatum(constraint->relname));
ScanKeyInit(&skey[1],
Anum_pg_constraint_connamespace,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(namespaceId));
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
conscan = systable_beginscan(conrel, ConstraintNameNspIndexId,
true, SnapshotNow, 2, skey);
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
while (HeapTupleIsValid(tup = systable_getnext(conscan)))
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
Form_pg_constraint con = (Form_pg_constraint) GETSTRUCT(tup);
if (con->condeferrable)
conoidlist = lappend_oid(conoidlist,
HeapTupleGetOid(tup));
else if (stmt->deferred)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("constraint \"%s\" is not deferrable",
constraint->relname)));
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
found = true;
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
}
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
systable_endscan(conscan);
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
/*
* Once we've found a matching constraint we do not search
* later parts of the search path.
*/
if (found)
break;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
list_free(namespacelist);
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
/*
* Not found ?
*/
if (!found)
Another round of error message editing, covering backend/commands/.
2003-07-20 23:56:35 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
errmsg("constraint \"%s\" does not exist",
Use schema search path to find the first matching contraint name for SET CONSTRAINT, rather than affecting all constraints in all schemas (which is what we used to do). Also allow schema specifications. Kris Jurka
2006-04-27 02:33:46 +02:00
constraint->relname)));
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
}
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
heap_close(conrel, AccessShareLock);
/*
* Now, locate the trigger(s) implementing each of these constraints,
* and make a list of their OIDs.
*/
tgrel = heap_open(TriggerRelationId, AccessShareLock);
foreach(lc, conoidlist)
{
Oid conoid = lfirst_oid(lc);
bool found;
ScanKeyData skey;
SysScanDesc tgscan;
HeapTuple htup;
found = false;
ScanKeyInit(&skey,
Anum_pg_trigger_tgconstraint,
BTEqualStrategyNumber, F_OIDEQ,
ObjectIdGetDatum(conoid));
tgscan = systable_beginscan(tgrel, TriggerConstraintIndexId, true,
SnapshotNow, 1, &skey);
while (HeapTupleIsValid(htup = systable_getnext(tgscan)))
{
Form_pg_trigger pg_trigger = (Form_pg_trigger) GETSTRUCT(htup);
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Silently skip triggers that are marked as non-deferrable in
* pg_trigger. This is not an error condition, since a
* deferrable RI constraint may have some non-deferrable
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* actions.
*/
if (pg_trigger->tgdeferrable)
tgoidlist = lappend_oid(tgoidlist,
HeapTupleGetOid(htup));
found = true;
}
systable_endscan(tgscan);
/* Safety check: a deferrable constraint should have triggers */
if (!found)
elog(ERROR, "no triggers found for constraint with OID %u",
conoid);
}
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
heap_close(tgrel, AccessShareLock);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
* Now we can set the trigger states of individual triggers for this
* xact.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
foreach(lc, tgoidlist)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
Oid tgoid = lfirst_oid(lc);
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
SetConstraintState state = afterTriggers->state;
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
bool found = false;
int i;
Minor efficiency improvements in keeping track of trigger deferred status. In particular, I see no reason for deferredTriggerCheckState to make an explicit entry to note that a particular trigger has its default state --- that just clutters a list that should normally be empty or very short. I have plans to revise this module much more heavily, but this is a simple separable improvement.
2004-09-09 01:47:58 +02:00
for (i = 0; i < state->numstates; i++)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (state->trigstates[i].sct_tgoid == tgoid)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
state->trigstates[i].sct_tgisdeferred = stmt->deferred;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
found = true;
break;
}
}
if (!found)
{
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
afterTriggers->state =
SetConstraintStateAddItem(state, tgoid, stmt->deferred);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
}
}
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* SQL99 requires that when a constraint is set to IMMEDIATE, any deferred
* checks against that constraint must be made when the SET CONSTRAINTS
* command is executed -- i.e. the effects of the SET CONSTRAINTS command
* apply retroactively. We've updated the constraints state, so scan the
* list of previously deferred events to fire any that have now become
* immediate.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* Obviously, if this was SET ... DEFERRED then it can't have converted
* any unfired events to immediate, so we need do nothing in that case.
Improve documentation of trigger firing queue handling, cleanup. Neil Conway
2002-08-17 14:15:49 +02:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (!stmt->deferred)
{
AfterTriggerEventList *events = &afterTriggers->events;
Fix failure to ensure that a snapshot is available to datatype input functions when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary.
2008-12-13 03:00:20 +01:00
bool snapshot_set = false;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Repair problems occurring when multiple RI updates have to be done to the same row within one query: we were firing check triggers before all the updates were done, leading to bogus failures. Fix by making the triggers queued by an RI update go at the end of the outer query's trigger event list, thereby effectively making the processing "breadth-first". This was indeed how it worked pre-8.0, so the bug does not occur in the 7.x branches. Per report from Pavel Stehule.
2007-08-15 21:15:47 +02:00
while (afterTriggerMarkEvents(events, NULL, true))
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CommandId firing_id = afterTriggers->firing_counter++;
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
Fix failure to ensure that a snapshot is available to datatype input functions when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary.
2008-12-13 03:00:20 +01:00
/*
* Make sure a snapshot has been established in case trigger
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* functions need one. Note that we avoid setting a snapshot if
Fix failure to ensure that a snapshot is available to datatype input functions when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary.
2008-12-13 03:00:20 +01:00
* we don't find at least one trigger that has to be fired now.
* This is so that BEGIN; SET CONSTRAINTS ...; SET TRANSACTION
* ISOLATION LEVEL SERIALIZABLE; ... works properly. (If we are
* at the start of a transaction it's not possible for any trigger
* events to be queued yet.)
*/
if (!snapshot_set)
{
PushActiveSnapshot(GetTransactionSnapshot());
snapshot_set = true;
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We can delete fired events if we are at top transaction level,
* but we'd better not if inside a subtransaction, since the
* subtransaction could later get rolled back.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (afterTriggerInvokeEvents(events, firing_id, NULL,
!IsSubTransaction()))
break; /* all fired */
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
}
Fix failure to ensure that a snapshot is available to datatype input functions when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary.
2008-12-13 03:00:20 +01:00
if (snapshot_set)
PopActiveSnapshot();
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
/* ----------
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
* AfterTriggerPendingOnRel()
* Test to see if there are any pending after-trigger events for rel.
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
*
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
* This is used by TRUNCATE, CLUSTER, ALTER TABLE, etc to detect whether
* it is unsafe to perform major surgery on a relation. Note that only
* local pending events are examined. We assume that having exclusive lock
* on a rel guarantees there are no unserviced events in other backends ---
* but having a lock does not prevent there being such events in our own.
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
*
* In some scenarios it'd be reasonable to remove pending events (more
* specifically, mark them DONE by the current subxact) but without a lot
* of knowledge of the trigger semantics we can't do this in general.
* ----------
*/
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
bool
AfterTriggerPendingOnRel(Oid relid)
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
{
AfterTriggerEvent event;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEventChunk *chunk;
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
int depth;
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
/* No-op if we aren't in a transaction. (Shouldn't happen?) */
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
if (afterTriggers == NULL)
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
return false;
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
/* Scan queued events */
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for_each_event_chunk(event, chunk, afterTriggers->events)
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerShared evtshared = GetTriggerSharedData(event);
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* We can ignore completed events. (Even if a DONE flag is rolled
* back by subxact abort, it's OK because the effects of the TRUNCATE
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
* or whatever must get rolled back too.)
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (event->ate_flags & AFTER_TRIGGER_DONE)
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
continue;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (evtshared->ats_relid == relid)
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
return true;
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
}
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Also scan events queued by incomplete queries. This could only matter
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
* if TRUNCATE/etc is executed by a function or trigger within an updating
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* query on the same relation, which is pretty perverse, but let's check.
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
*/
for (depth = 0; depth <= afterTriggers->query_depth; depth++)
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
for_each_event_chunk(event, chunk, afterTriggers->query_stack[depth])
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
{
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerShared evtshared = GetTriggerSharedData(event);
if (event->ate_flags & AFTER_TRIGGER_DONE)
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
continue;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
if (evtshared->ats_relid == relid)
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
return true;
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
}
}
Forbid ALTER TABLE and CLUSTER when there are pending AFTER-trigger events in the current backend for the target table. These operations move tuples around and would thus invalidate the TIDs stored in the trigger event records. (We need not worry about events in other backends, since acquiring exclusive lock should be enough to ensure there aren't any.) It might be sufficient to forbid only the table-rewriting variants of ALTER TABLE, but in the absence of any compelling use-case, let's just be safe and simple. Per follow-on investigation of bug #3847, though this is not actually the same problem reported therein. Possibly this should be back-patched, but since the case has never been reported from the field, I didn't bother.
2008-01-03 00:34:42 +01:00
return false;
Disallow TRUNCATE when there are any pending after-trigger events for the target relation(s). There might be some cases where we could discard the pending event instead, but for the moment a conservative approach seems sufficient. Per report from Markus Schiltknecht and subsequent discussion.
2006-09-04 23:15:56 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
/* ----------
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
* AfterTriggerSaveEvent()
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
* Called by ExecA[RS]...Triggers() to queue up the triggers that should
* be fired for an event.
Looks like I broke cases involving combinations of deferred update/delete triggers ... oops ... but the regress tests should have covered this ...
2001-01-27 06:16:58 +01:00
*
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
* NOTE: this is called whenever there are any triggers associated with
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* the event (even if they are disabled). This function decides which
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
* triggers actually need to be queued.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
* ----------
*/
Mark functions as static and ifdef NOT_USED as appropriate.
2000-06-09 00:38:00 +02:00
static void
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
AfterTriggerSaveEvent(EState *estate, ResultRelInfo *relinfo,
int event, bool row_trigger,
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
HeapTuple oldtup, HeapTuple newtup,
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
List *recheckIndexes, Bitmapset *modifiedCols)
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
{
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
Relation rel = relinfo->ri_RelationDesc;
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
AfterTriggerEventData new_event;
AfterTriggerSharedData new_shared;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
int i;
int ntriggers;
Clean up some minor problems exposed by further thought about Panon's bug report on old-style functions invoked by RI triggers. We had a number of other places that were being sloppy about which memory context FmgrInfo subsidiary data will be allocated in. Turns out none of them actually cause a problem in 7.1, but this is for arcane reasons such as the fact that old-style triggers aren't supported anyway. To avoid getting burnt later, I've restructured the trigger support so that we don't keep trigger FmgrInfo structs in relcache memory. Some other related cleanups too: it's not really necessary to call fmgr_info at all while setting up the index support info in relcache entries, because those ScanKeyEntry structs are never used to invoke the functions. This should speed up relcache initialization a tiny bit.
2001-06-01 04:41:36 +02:00
int *tgindx;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Fix AfterTriggerSaveEvent to use a test and elog, not just Assert, to check that it's called within an AfterTriggerBeginQuery/AfterTriggerEndQuery pair. The RI cascade triggers suppress that overhead on the assumption that they are always run non-deferred, so it's possible to violate the condition if someone mistakenly changes pg_trigger to mark such a trigger deferred. We don't really care about supporting that, but throwing an error instead of crashing seems desirable. Per report from Marcelo Costa.
2009-10-27 21:14:27 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Check state. We use normal tests not Asserts because it is possible to
* reach here in the wrong state given misconfigured RI triggers, in
* particular deferring a cascade action trigger.
Fix AfterTriggerSaveEvent to use a test and elog, not just Assert, to check that it's called within an AfterTriggerBeginQuery/AfterTriggerEndQuery pair. The RI cascade triggers suppress that overhead on the assumption that they are always run non-deferred, so it's possible to violate the condition if someone mistakenly changes pg_trigger to mark such a trigger deferred. We don't really care about supporting that, but throwing an error instead of crashing seems desirable. Per report from Marcelo Costa.
2009-10-27 21:14:27 +01:00
*/
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
if (afterTriggers == NULL)
elog(ERROR, "AfterTriggerSaveEvent() called outside of transaction");
Fix AfterTriggerSaveEvent to use a test and elog, not just Assert, to check that it's called within an AfterTriggerBeginQuery/AfterTriggerEndQuery pair. The RI cascade triggers suppress that overhead on the assumption that they are always run non-deferred, so it's possible to violate the condition if someone mistakenly changes pg_trigger to mark such a trigger deferred. We don't really care about supporting that, but throwing an error instead of crashing seems desirable. Per report from Marcelo Costa.
2009-10-27 21:14:27 +01:00
if (afterTriggers->query_depth < 0)
elog(ERROR, "AfterTriggerSaveEvent() called outside of query");
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
/*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Validate the event code and collect the associated tuple CTIDs.
*
* The event code will be used both as a bitmask and an array offset, so
* validation is important to make sure we don't walk off the edge of our
* arrays.
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
new_event.ate_flags = 0;
switch (event)
{
case TRIGGER_EVENT_INSERT:
if (row_trigger)
{
Assert(oldtup == NULL);
Assert(newtup != NULL);
ItemPointerCopy(&(newtup->t_self), &(new_event.ate_ctid1));
ItemPointerSetInvalid(&(new_event.ate_ctid2));
}
else
{
Assert(oldtup == NULL);
Assert(newtup == NULL);
ItemPointerSetInvalid(&(new_event.ate_ctid1));
ItemPointerSetInvalid(&(new_event.ate_ctid2));
}
break;
case TRIGGER_EVENT_DELETE:
if (row_trigger)
{
Assert(oldtup != NULL);
Assert(newtup == NULL);
ItemPointerCopy(&(oldtup->t_self), &(new_event.ate_ctid1));
ItemPointerSetInvalid(&(new_event.ate_ctid2));
}
else
{
Assert(oldtup == NULL);
Assert(newtup == NULL);
ItemPointerSetInvalid(&(new_event.ate_ctid1));
ItemPointerSetInvalid(&(new_event.ate_ctid2));
}
break;
case TRIGGER_EVENT_UPDATE:
if (row_trigger)
{
Assert(oldtup != NULL);
Assert(newtup != NULL);
ItemPointerCopy(&(oldtup->t_self), &(new_event.ate_ctid1));
ItemPointerCopy(&(newtup->t_self), &(new_event.ate_ctid2));
new_event.ate_flags |= AFTER_TRIGGER_2CTIDS;
}
else
{
Assert(oldtup == NULL);
Assert(newtup == NULL);
ItemPointerSetInvalid(&(new_event.ate_ctid1));
ItemPointerSetInvalid(&(new_event.ate_ctid2));
}
break;
case TRIGGER_EVENT_TRUNCATE:
Assert(oldtup == NULL);
Assert(newtup == NULL);
ItemPointerSetInvalid(&(new_event.ate_ctid1));
ItemPointerSetInvalid(&(new_event.ate_ctid2));
break;
default:
elog(ERROR, "invalid after-trigger event code: %d", event);
break;
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
* Scan the appropriate set of triggers
*/
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
if (row_trigger)
{
ntriggers = trigdesc->n_after_row[event];
tgindx = trigdesc->tg_after_row[event];
}
else
{
ntriggers = trigdesc->n_after_statement[event];
tgindx = trigdesc->tg_after_statement[event];
}
This trivial patch implements disabled, deferred triggers, per my proposal on -hackers a couple days ago. The 'tgenabled' status of the trigger is consulted when the trigger is added to the deferred queue (i.e. when the event occurs that fires the trigger), not when the deferred event is executed. No regression tests, as another bug prevents them (the pg_trigger row for a trigger is only loaded once per session, so any changes to it are not noticed unless the client disconnects and reconnects). Neil Conway
2003-01-08 23:28:32 +01:00
for (i = 0; i < ntriggers; i++)
{
pgindent run.
2003-08-04 02:43:34 +02:00
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
This trivial patch implements disabled, deferred triggers, per my proposal on -hackers a couple days ago. The 'tgenabled' status of the trigger is consulted when the trigger is added to the deferred queue (i.e. when the event occurs that fires the trigger), not when the deferred event is executed. No regression tests, as another bug prevents them (the pg_trigger row for a trigger is only loaded once per session, so any changes to it are not noticed unless the client disconnects and reconnects). Neil Conway
2003-01-08 23:28:32 +01:00
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
if (!TriggerEnabled(estate, relinfo, trigger, event,
modifiedCols, oldtup, newtup))
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
continue;
This trivial patch implements disabled, deferred triggers, per my proposal on -hackers a couple days ago. The 'tgenabled' status of the trigger is consulted when the trigger is added to the deferred queue (i.e. when the event occurs that fires the trigger), not when the deferred event is executed. No regression tests, as another bug prevents them (the pg_trigger row for a trigger is only loaded once per session, so any changes to it are not noticed unless the client disconnects and reconnects). Neil Conway
2003-01-08 23:28:32 +01:00
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If this is an UPDATE of a PK table or FK table that does not change
* the PK or FK respectively, we can skip queuing the event: there is
* no need to fire the trigger.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*/
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
if (TRIGGER_FIRED_BY_UPDATE(event))
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
switch (RI_FKey_trigger_type(trigger->tgfoid))
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
{
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
case RI_TRIGGER_PK:
/* Update on PK table */
if (RI_FKey_keyequal_upd_pk(trigger, rel, oldtup, newtup))
{
/* key unchanged, so skip queuing this event */
continue;
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
break;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
case RI_TRIGGER_FK:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
/*
* Update on FK table
*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* There is one exception when updating FK tables: if the
* updated row was inserted by our own transaction and the
* FK is deferred, we still need to fire the trigger. This
* is because our UPDATE will invalidate the INSERT so the
* end-of-transaction INSERT RI trigger will not do
* anything, so we have to do the check for the UPDATE
* anyway.
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
*/
Fix incorrect optimization of foreign-key checks. When an UPDATE on the referencing table does not change the tuple's FK column(s), we don't bother to check the PK table since the constraint was presumably already valid. However, the check is still necessary if the tuple was inserted by our own transaction, since in that case the INSERT trigger will conclude it need not make the check (since its version of the tuple has been deleted). We got this right for simple cases, but not when the insert and update are in different subtransactions of the current top-level transaction; in such cases the FK check would never be made at all. (Hence, problem dates back to 8.0 when subtransactions were added --- it's actually the subtransaction version of a bug fixed in 7.3.5.) Fix, and add regression test cases. Report and fix by Affan Salman.
2007-07-17 19:45:28 +02:00
if (!TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(oldtup->t_data)) &&
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
RI_FKey_keyequal_upd_fk(trigger, rel, oldtup, newtup))
{
continue;
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
break;
pgindent run.
2002-09-04 22:31:48 +02:00
When enqueueing after-row triggers for updates of a table with a foreign key, compare the new and old row versions. If the foreign key column has not changed, we needn't enqueue the trigger, since the update cannot violate the foreign key. This optimization was previously applied in the RI trigger function, but it is more efficient to avoid firing the trigger altogether. Per recent discussion on pgsql-hackers. Also add a regression test for some unintuitive foreign key behavior, and refactor some code that deals with the OIDs of the various RI trigger functions.
2005-05-30 09:20:59 +02:00
case RI_TRIGGER_NONE:
/* Not an FK trigger */
break;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
}
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* If the trigger is a deferred unique constraint check trigger, only
* queue it if the unique constraint was potentially violated, which
* we know from index insertion time.
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
*/
if (trigger->tgfoid == F_UNIQUE_KEY_RECHECK)
{
if (!list_member_oid(recheckIndexes, trigger->tgconstrindid))
continue; /* Uniqueness definitely not violated */
}
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
/*
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
* Fill in event structure and add it to the current query's queue.
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
*/
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
new_shared.ats_event =
Fire non-deferred AFTER triggers immediately upon query completion, rather than when returning to the idle loop. This makes no particular difference for interactively-issued queries, but it makes a big difference for queries issued within functions: trigger execution now occurs before the calling function is allowed to proceed. This responds to numerous complaints about nonintuitive behavior of foreign key checking, such as http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and appears to be required by the SQL99 spec. Also take the opportunity to simplify the data structures used for the pending-trigger list, rename them for more clarity, and squeeze out a bit of space.
2004-09-10 20:40:09 +02:00
(event & TRIGGER_EVENT_OPMASK) |
(row_trigger ? TRIGGER_EVENT_ROW : 0) |
(trigger->tgdeferrable ? AFTER_TRIGGER_DEFERRABLE : 0) |
(trigger->tginitdeferred ? AFTER_TRIGGER_INITDEFERRED : 0);
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
new_shared.ats_tgoid = trigger->tgoid;
new_shared.ats_relid = RelationGetRelid(rel);
new_shared.ats_firing_id = 0;
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
Reduce the memory footprint of large pending-trigger-event lists, as per my recent proposal. In typical cases, we now need 12 bytes per insert or delete event and 16 bytes per update event; previously we needed 40 bytes per event on 32-bit hardware and 80 bytes per event on 64-bit hardware. Even in the worst case usage pattern with a large number of distinct triggers being fired in one query, usage is at most 32 bytes per event. It seems to be a bit faster than the old code as well, due to reduction of palloc overhead. This commit doesn't address the TODO item of allowing the event list to spill to disk; rather it's trying to stave off the need for that. However, it probably makes that task a bit easier by reducing the data structure's dependency on pointers. It would now be practical to dump an event list to disk by "chunks" instead of individual events.
2008-10-25 01:42:35 +02:00
afterTriggerAddEvent(&afterTriggers->query_stack[afterTriggers->query_depth],
&new_event, &new_shared);
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands. TODO: Generic builtin trigger procedures Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE Support of new trigger type in pg_dump Swapping of huge # of events to disk Jan
1999-09-29 18:06:40 +02:00
}
}