<!--
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">
<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>
<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>
<!--
-$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
-->
<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>
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>
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>