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, 19 insertions, 4 deletions

diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 83e9845103a..57d74e14d75 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -1820,10 +1820,17 @@ describeOneTableDetails(const char *schemaname,
 			}
 			PQclear(result);
 		}
+	}
+
+	/*
+	 * Print triggers next, if any (but only user-defined triggers).  This
+	 * could apply to either a table or a view.
+	 */
+	if (tableinfo.hastriggers)
+	{
+			PGresult   *result;
+			int			tuples;
 
-		/* print triggers (but only user-defined triggers) */
-		if (tableinfo.hastriggers)
-		{
 			printfPQExpBuffer(&buf,
 							  "SELECT t.tgname, "
 							  "pg_catalog.pg_get_triggerdef(t.oid%s), "
@@ -1934,7 +1941,15 @@ describeOneTableDetails(const char *schemaname,
 				}
 			}
 			PQclear(result);
-		}
+	}
+
+	/*
+	 * Finish printing the footer information about a table.
+	 */
+	if (tableinfo.relkind == 'r')
+	{
+		PGresult   *result;
+		int			tuples;
 
 		/* print inherited tables */
 		printfPQExpBuffer(&buf, "SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhparent AND i.inhrelid = '%s' ORDER BY inhseqno", oid);