Support triggers on views.

This patch adds the SQL-standard concept of an INSTEAD OF trigger, which
is fired instead of performing a physical insert/update/delete.  The
trigger function is passed the entire old and/or new rows of the view,
and must figure out what to do to the underlying tables to implement
the update.  So this feature can be used to implement updatable views
using trigger programming style rather than rule hacking.

In passing, this patch corrects the names of some columns in the
information_schema.triggers view.  It seems the SQL committee renamed
them somewhere between SQL:99 and SQL:2003.

Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.

1 files changed, 8 insertions, 42 deletions

diff --git a/src/backend/optimizer/prep/preptlist.c b/src/backend/optimizer/prep/preptlist.c
index a8464a7aa0b..2c97c71472a 100644
--- a/src/backend/optimizer/prep/preptlist.c
+++ b/src/backend/optimizer/prep/preptlist.c
@@ -3,14 +3,14 @@
  * preptlist.c
  *	  Routines to preprocess the parse tree target list
  *
- * This module takes care of altering the query targetlist as needed for
- * INSERT, UPDATE, and DELETE queries.	For INSERT and UPDATE queries,
- * the targetlist must contain an entry for each attribute of the target
- * relation in the correct order.  For both UPDATE and DELETE queries,
- * we need a junk targetlist entry holding the CTID attribute --- the
- * executor relies on this to find the tuple to be replaced/deleted.
- * We may also need junk tlist entries for Vars used in the RETURNING list
- * and row ID information needed for EvalPlanQual checking.
+ * For INSERT and UPDATE queries, the targetlist must contain an entry for
+ * each attribute of the target relation in the correct order.  For all query
+ * types, we may need to add junk tlist entries for Vars used in the RETURNING
+ * list and row ID information needed for EvalPlanQual checking.
+ *
+ * NOTE: the rewriter's rewriteTargetListIU and rewriteTargetListUD
+ * routines also do preprocessing of the targetlist.  The division of labor
+ * between here and there is a bit arbitrary and historical.
  *
  *
  * Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
@@ -78,37 +78,6 @@ preprocess_targetlist(PlannerInfo *root, List *tlist)
 								  result_relation, range_table);
 
 	/*
-	 * for "update" and "delete" queries, add ctid of the result relation into
-	 * the target list so that the ctid will propagate through execution and
-	 * ExecutePlan() will be able to identify the right tuple to replace or
-	 * delete.	This extra field is marked "junk" so that it is not stored
-	 * back into the tuple.
-	 */
-	if (command_type == CMD_UPDATE || command_type == CMD_DELETE)
-	{
-		TargetEntry *tle;
-		Var		   *var;
-
-		var = makeVar(result_relation, SelfItemPointerAttributeNumber,
-					  TIDOID, -1, 0);
-
-		tle = makeTargetEntry((Expr *) var,
-							  list_length(tlist) + 1,
-							  pstrdup("ctid"),
-							  true);
-
-		/*
-		 * For an UPDATE, expand_targetlist already created a fresh tlist. For
-		 * DELETE, better do a listCopy so that we don't destructively modify
-		 * the original tlist (is this really necessary?).
-		 */
-		if (command_type == CMD_DELETE)
-			tlist = list_copy(tlist);
-
-		tlist = lappend(tlist, tle);
-	}
-
-	/*
 	 * Add necessary junk columns for rowmarked rels.  These values are needed
 	 * for locking of rels selected FOR UPDATE/SHARE, and to do EvalPlanQual
 	 * rechecking.	While we are at it, store these junk attnos in the
@@ -235,9 +204,6 @@ preprocess_targetlist(PlannerInfo *root, List *tlist)
  *	  Given a target list as generated by the parser and a result relation,
  *	  add targetlist entries for any missing attributes, and ensure the
  *	  non-junk attributes appear in proper field order.
- *
- * NOTE: if you are tempted to put more processing here, consider whether
- * it shouldn't go in the rewriter's rewriteTargetList() instead.
  */
 static List *
 expand_targetlist(List *tlist, int command_type,