Improvement to CREATE TRIGGER and catalog documentation.

Neil Conway
This commit is contained in:
Bruce Momjian 2002-12-17 17:41:30 +00:00
parent e5bdd8d6f8
commit 49077e87af
2 changed files with 24 additions and 14 deletions

View File

@ -1,6 +1,6 @@
<!--
Documentation of the system catalogs, directed toward PostgreSQL developers
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.63 2002/10/14 04:29:23 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.64 2002/12/17 17:41:30 momjian Exp $
-->
<chapter id="catalogs">
@ -1068,9 +1068,12 @@
<entry>relhasindex</entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>True if this is a table and it has (or recently had) any indexes.
This is set by CREATE INDEX, but not cleared immediately by DROP INDEX.
VACUUM clears relhasindex if it finds the table has no indexes.
<entry>
True if this is a table and it has (or recently had) any
indexes. This is set by <command>CREATE INDEX</command>, but
not cleared immediately by <command>DROP INDEX</command>.
<command>VACUUM</command> clears relhasindex if it finds the
table has no indexes.
</entry>
</row>
@ -2049,11 +2052,11 @@
<entry><type>bool</type></entry>
<entry></entry>
<entry>
This is false for internal languages (such as SQL) and true for
user-defined languages. Currently,
<application>pg_dump</application> still uses this to determine
which languages need to be dumped, but this may be replaced by
a different mechanism sometime.
This is false for internal languages (such as
<acronym>SQL</acronym>) and true for user-defined languages.
Currently, <application>pg_dump</application> still uses this
to determine which languages need to be dumped, but this may be
replaced by a different mechanism sometime.
</entry>
</row>

View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.30 2002/11/23 03:59:06 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.31 2002/12/17 17:41:30 momjian Exp $
PostgreSQL documentation
-->
@ -21,9 +21,8 @@ PostgreSQL documentation
<date>2000-03-25</date>
</refsynopsisdivinfo>
<synopsis>
CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> {
BEFORE | AFTER } { <replaceable class="PARAMETER">event</replaceable> [ OR ... ] }
ON <replaceable class="PARAMETER">table</replaceable> [ FOR EACH { ROW | STATEMENT } ]
CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTER } { <replaceable class="PARAMETER">event</replaceable> [ OR ... ] }
ON <replaceable class="PARAMETER">table</replaceable> [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE PROCEDURE <replaceable class="PARAMETER">func</replaceable> ( <replaceable class="PARAMETER">arguments</replaceable> )
</synopsis>
@ -186,7 +185,9 @@ CREATE TRIGGER
deleted tuple. In contrast, a trigger that executes <literal>FOR
EACH STATEMENT</literal> of the specified operation only executes
once for any given operation, regardless of how many rows it
modifies.
modifies (in particular, an operation that modifies zero rows will
still result in the execution of any applicable <literal>FOR EACH
STATEMENT</literal> triggers).
</para>
<para>
@ -330,6 +331,12 @@ CREATE TABLE distributors (
time-of-creation order. <productname>PostgreSQL</productname>
uses name order, which was judged more convenient to work with.
</para>
<para>
The ability to specify multiple actions for a single trigger
using <literal>OR</literal> is a <productname>PostgreSQL</>
extension of the SQL standard.
</para>
</listitem>
</varlistentry>
</variablelist>