mirror of
				https://github.com/postgres/postgres.git
				synced 2025-11-03 00:08:23 -05:00 
			
		
		
		
	More editing of reference pages.
This commit is contained in:
		
							parent
							
								
									8a703496a2
								
							
						
					
					
						commit
						3450fd08a9
					
				@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.24 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.25 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -10,166 +10,40 @@ PostgreSQL documentation
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE AGGREGATE
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new aggregate function
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE AGGREGATE</refname>
 | 
			
		||||
  <refpurpose>define a new aggregate function</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2000-07-16</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
CREATE AGGREGATE <replaceable class="PARAMETER">name</replaceable> ( BASETYPE = <replaceable class="PARAMETER">input_data_type</replaceable>,
 | 
			
		||||
    SFUNC = <replaceable class="PARAMETER">sfunc</replaceable>, STYPE = <replaceable class="PARAMETER">state_type</replaceable>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE AGGREGATE <replaceable class="PARAMETER">name</replaceable> (
 | 
			
		||||
    BASETYPE = <replaceable class="PARAMETER">input_data_type</replaceable>,
 | 
			
		||||
    SFUNC = <replaceable class="PARAMETER">sfunc</replaceable>,
 | 
			
		||||
    STYPE = <replaceable class="PARAMETER">state_data_type</replaceable>
 | 
			
		||||
    [ , FINALFUNC = <replaceable class="PARAMETER">ffunc</replaceable> ]
 | 
			
		||||
    [ , INITCOND = <replaceable class="PARAMETER">initial_condition</replaceable> ] )
 | 
			
		||||
  </synopsis>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEAGGREGATE-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-07-16</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name (optionally schema-qualified) of an aggregate function to
 | 
			
		||||
	create.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">input_data_type</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The input data type on which this aggregate function operates.
 | 
			
		||||
	This can be specified as <literal>"ANY"</> for an aggregate that does
 | 
			
		||||
	not examine its input values
 | 
			
		||||
	(an example is <function>count(*)</function>).
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">sfunc</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of the state transition function
 | 
			
		||||
	to be called for each input data value.
 | 
			
		||||
	This is normally a function of two arguments, the first being of
 | 
			
		||||
	type <replaceable class="PARAMETER">state_type</replaceable>
 | 
			
		||||
	and the second of
 | 
			
		||||
	type <replaceable class="PARAMETER">input_data_type</replaceable>.
 | 
			
		||||
	Alternatively, for an aggregate that does not examine its input
 | 
			
		||||
	values, the function takes just one argument of
 | 
			
		||||
	type <replaceable class="PARAMETER">state_type</replaceable>.
 | 
			
		||||
	In either case the function must return a value of
 | 
			
		||||
	type <replaceable class="PARAMETER">state_type</replaceable>.
 | 
			
		||||
	This function takes the current state value and the current
 | 
			
		||||
	input data item, and returns the next state value.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">state_type</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The data type for the aggregate's state value.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">ffunc</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of the final function called to compute the aggregate's
 | 
			
		||||
	result after all input data has been traversed.  The function
 | 
			
		||||
	must take a single argument of type
 | 
			
		||||
	<replaceable class="PARAMETER">state_type</replaceable>.
 | 
			
		||||
	The output data type of the aggregate is defined as the return
 | 
			
		||||
	type of this function.
 | 
			
		||||
	If <replaceable class="PARAMETER">ffunc</replaceable>
 | 
			
		||||
	is not specified, then the ending state value is used as the
 | 
			
		||||
	aggregate's result, and the output type is
 | 
			
		||||
	<replaceable class="PARAMETER">state_type</replaceable>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">initial_condition</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The initial setting for the state value.  This must be a literal
 | 
			
		||||
	constant in the form accepted for the data type
 | 
			
		||||
	<replaceable class="PARAMETER">state_type</replaceable>.
 | 
			
		||||
	If not specified, the state value starts out NULL.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEAGGREGATE-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-09</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE AGGREGATE
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the command completes successfully.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
    [ , INITCOND = <replaceable class="PARAMETER">initial_condition</replaceable> ]
 | 
			
		||||
)
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEAGGREGATE-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2000-07-16</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE AGGREGATE</command> 
 | 
			
		||||
   allows a user or programmer to extend <productname>PostgreSQL</productname>
 | 
			
		||||
   functionality by defining new aggregate functions. Some aggregate functions
 | 
			
		||||
   <command>CREATE AGGREGATE</command> defines a new aggregate function. Some aggregate functions
 | 
			
		||||
   for base types such as <function>min(integer)</function>
 | 
			
		||||
   and <function>avg(double precision)</function> are already provided in the base
 | 
			
		||||
   and <function>avg(double precision)</function> are already provided in the standard
 | 
			
		||||
   distribution. If one defines new types or needs an aggregate function not
 | 
			
		||||
   already provided, then <command>CREATE AGGREGATE</command>
 | 
			
		||||
   can be used to provide the desired features.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given (for example, <literal>CREATE AGGREGATE
 | 
			
		||||
   myschema.myagg ...</>) then the aggregate function is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   An  aggregate  function is identified by its name and input data type.
 | 
			
		||||
   Two aggregates in the same schema can have the same name if they operate on
 | 
			
		||||
@ -178,6 +52,7 @@ CREATE AGGREGATE
 | 
			
		||||
   the name and input data type(s) of every ordinary function in the same
 | 
			
		||||
   schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   An  aggregate function is made from one or two ordinary
 | 
			
		||||
   functions:
 | 
			
		||||
@ -186,11 +61,12 @@ CREATE AGGREGATE
 | 
			
		||||
   and an optional final calculation function
 | 
			
		||||
   <replaceable class="PARAMETER">ffunc</replaceable>.
 | 
			
		||||
   These are used as follows:
 | 
			
		||||
   <programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
<replaceable class="PARAMETER">sfunc</replaceable>( internal-state, next-data-item ) ---> next-internal-state
 | 
			
		||||
<replaceable class="PARAMETER">ffunc</replaceable>( internal-state ) ---> aggregate-value
 | 
			
		||||
   </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <productname>PostgreSQL</productname> creates a temporary variable
 | 
			
		||||
   of data type <replaceable class="PARAMETER">stype</replaceable>
 | 
			
		||||
@ -198,7 +74,7 @@ CREATE AGGREGATE
 | 
			
		||||
   data item,
 | 
			
		||||
   the state transition function is invoked to calculate a new
 | 
			
		||||
   internal state value.  After all the data has been processed,
 | 
			
		||||
   the final function is invoked once to calculate the aggregate's output
 | 
			
		||||
   the final function is invoked once to calculate the aggregate's return
 | 
			
		||||
   value.  If there is no final function then the ending state value
 | 
			
		||||
   is returned as-is.
 | 
			
		||||
  </para>
 | 
			
		||||
@ -206,67 +82,163 @@ CREATE AGGREGATE
 | 
			
		||||
  <para>
 | 
			
		||||
   An aggregate function may provide an initial condition,
 | 
			
		||||
   that is, an initial value for the internal state value.
 | 
			
		||||
   This is specified and stored in the database as a field of type
 | 
			
		||||
   This is specified and stored in the database as a column of type
 | 
			
		||||
   <type>text</type>, but it must be a valid external representation
 | 
			
		||||
   of a constant of the state value data type.  If it is not supplied
 | 
			
		||||
   then the state value starts out NULL.
 | 
			
		||||
   then the state value starts out null.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <para>
 | 
			
		||||
   If the state transition function is declared <quote>strict</quote>,
 | 
			
		||||
   then it cannot be called with NULL inputs.  With such a transition
 | 
			
		||||
   function, aggregate execution behaves as follows.  NULL input values
 | 
			
		||||
   then it cannot be called with null inputs.  With such a transition
 | 
			
		||||
   function, aggregate execution behaves as follows.  Null input values
 | 
			
		||||
   are ignored (the function is not called and the previous state value
 | 
			
		||||
   is retained).  If the initial state value is NULL, then the first
 | 
			
		||||
   non-NULL input value replaces the state value, and the transition
 | 
			
		||||
   function is invoked beginning with the second non-NULL input value.
 | 
			
		||||
   is retained).  If the initial state value is null, then the first
 | 
			
		||||
   nonnull input value replaces the state value, and the transition
 | 
			
		||||
   function is invoked beginning with the second nonnull input value.
 | 
			
		||||
   This is handy for implementing aggregates like <function>max</function>.
 | 
			
		||||
   Note that this behavior is only available when
 | 
			
		||||
   <replaceable class="PARAMETER">state_type</replaceable>
 | 
			
		||||
   <replaceable class="PARAMETER">state_data_type</replaceable>
 | 
			
		||||
   is the same as
 | 
			
		||||
   <replaceable class="PARAMETER">input_data_type</replaceable>.
 | 
			
		||||
   When these types are different, you must supply a non-NULL initial
 | 
			
		||||
   condition or use a non-strict transition function.
 | 
			
		||||
   When these types are different, you must supply a nonnull initial
 | 
			
		||||
   condition or use a nonstrict transition function.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <para>
 | 
			
		||||
   If the state transition function is not strict, then it will be called
 | 
			
		||||
   unconditionally at each input value, and must deal with NULL inputs
 | 
			
		||||
   and NULL transition values for itself.  This allows the aggregate
 | 
			
		||||
   unconditionally at each input value, and must deal with null inputs
 | 
			
		||||
   and null transition values for itself.  This allows the aggregate
 | 
			
		||||
   author to have full control over the aggregate's handling of null values.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <para>
 | 
			
		||||
   If the final function is declared <quote>strict</quote>, then it will not
 | 
			
		||||
   be called when the ending state value is NULL; instead a NULL result
 | 
			
		||||
   will be output automatically.  (Of course this is just the normal
 | 
			
		||||
   be called when the ending state value is null; instead a null result
 | 
			
		||||
   will be returned automatically.  (Of course this is just the normal
 | 
			
		||||
   behavior of strict functions.)  In any case the final function has
 | 
			
		||||
   the option of returning NULL.  For example, the final function for
 | 
			
		||||
   <function>avg</function> returns NULL when it sees there were zero
 | 
			
		||||
   input tuples.
 | 
			
		||||
   the option of returning a null value.  For example, the final function for
 | 
			
		||||
   <function>avg</function> returns null when it sees there were zero
 | 
			
		||||
   input rows.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEAGGREGATE-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-07-16</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    Use <command>DROP AGGREGATE</command>
 | 
			
		||||
    to drop aggregate functions.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The parameters of <command>CREATE AGGREGATE</command> can be written
 | 
			
		||||
    in any order, not just the order illustrated above.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEAGGREGATE-2">
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="PARAMETER">name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of the aggregate function
 | 
			
		||||
      to create.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="PARAMETER">input_data_type</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The input data type on which this aggregate function operates.
 | 
			
		||||
      This can be specified as <literal>"ANY"</> for an aggregate that
 | 
			
		||||
      does not examine its input values (an example is
 | 
			
		||||
      <function>count(*)</function>).
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="PARAMETER">sfunc</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of the state transition function to be called for each
 | 
			
		||||
      input data value.  This is normally a function of two arguments,
 | 
			
		||||
      the first being of type <replaceable
 | 
			
		||||
      class="PARAMETER">state_data_type</replaceable> and the second
 | 
			
		||||
      of type <replaceable
 | 
			
		||||
      class="PARAMETER">input_data_type</replaceable>.  Alternatively,
 | 
			
		||||
      for an aggregate that does not examine its input values, the
 | 
			
		||||
      function takes just one argument of type <replaceable
 | 
			
		||||
      class="PARAMETER">state_data_type</replaceable>.  In either case
 | 
			
		||||
      the function must return a value of type <replaceable
 | 
			
		||||
      class="PARAMETER">state_data_type</replaceable>.  This function
 | 
			
		||||
      takes the current state value and the current input data item,
 | 
			
		||||
      and returns the next state value.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="PARAMETER">state_data_type</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The data type for the aggregate's state value.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="PARAMETER">ffunc</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of the final function called to compute the aggregate's
 | 
			
		||||
      result after all input data has been traversed.  The function
 | 
			
		||||
      must take a single argument of type <replaceable
 | 
			
		||||
      class="PARAMETER">state_data_type</replaceable>.  The return
 | 
			
		||||
      data type of the aggregate is defined as the return type of this
 | 
			
		||||
      function.  If <replaceable class="PARAMETER">ffunc</replaceable>
 | 
			
		||||
      is not specified, then the ending state value is used as the
 | 
			
		||||
      aggregate's result, and the return type is <replaceable
 | 
			
		||||
      class="PARAMETER">state_data_type</replaceable>.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="PARAMETER">initial_condition</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The initial setting for the state value.  This must be a string
 | 
			
		||||
      constant in the form accepted for the data type <replaceable
 | 
			
		||||
      class="PARAMETER">state_data_type</replaceable>.  If not
 | 
			
		||||
      specified, the state value starts out null.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The parameters of <command>CREATE AGGREGATE</command> can be
 | 
			
		||||
   written in any order, not just the order illustrated above.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE AGGREGATE</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the command completes successfully.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
 <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <command>DROP AGGREGATE</command> to drop aggregate functions.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
@ -274,24 +246,14 @@ CREATE AGGREGATE
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEAGGREGATE-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEAGGREGATE-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-09</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE AGGREGATE</command> 
 | 
			
		||||
    is a <productname>PostgreSQL</productname> language extension.
 | 
			
		||||
    There is no <command>CREATE AGGREGATE</command> in SQL92.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE AGGREGATE</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> language extension.  The SQL
 | 
			
		||||
   standard does not provide for user-defined aggregate function.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,4 +1,4 @@
 | 
			
		||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/create_cast.sgml,v 1.10 2003/03/25 16:15:39 petere Exp $ -->
 | 
			
		||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/create_cast.sgml,v 1.11 2003/04/22 10:08:08 petere Exp $ -->
 | 
			
		||||
 | 
			
		||||
<refentry id="SQL-CREATECAST">
 | 
			
		||||
 <refmeta>
 | 
			
		||||
@ -58,11 +58,11 @@ SELECT CAST(42 AS text);
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If the cast is marked <literal>AS ASSIGNMENT</> then it can be invoked
 | 
			
		||||
   implicitly when assigning to a column of the target data type.
 | 
			
		||||
   implicitly when assigning a value to a column of the target data type.
 | 
			
		||||
   For example, supposing that <literal>foo.f1</literal> is a column of
 | 
			
		||||
   type <type>text</type>, then
 | 
			
		||||
<programlisting>
 | 
			
		||||
INSERT INTO foo(f1) VALUES(42);
 | 
			
		||||
INSERT INTO foo (f1) VALUES (42);
 | 
			
		||||
</programlisting>
 | 
			
		||||
   will be allowed if the cast from type <type>integer</type> to type
 | 
			
		||||
   <type>text</type> is marked <literal>AS ASSIGNMENT</>, otherwise
 | 
			
		||||
@ -75,7 +75,7 @@ INSERT INTO foo(f1) VALUES(42);
 | 
			
		||||
   If the cast is marked <literal>AS IMPLICIT</> then it can be invoked
 | 
			
		||||
   implicitly in any context, whether assignment or internally in an
 | 
			
		||||
   expression.  For example, since <literal>||</> takes <type>text</>
 | 
			
		||||
   arguments,
 | 
			
		||||
   operands,
 | 
			
		||||
<programlisting>
 | 
			
		||||
SELECT 'The time is ' || now();
 | 
			
		||||
</programlisting>
 | 
			
		||||
@ -106,14 +106,16 @@ SELECT 'The time is ' || CAST(now() AS text);
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To be able to create a cast, you must own the source or the target
 | 
			
		||||
   data type.  To create a binary-compatible cast, you must be superuser
 | 
			
		||||
   (this restriction is made because an erroneous binary-compatible cast
 | 
			
		||||
   conversion can easily crash the server).
 | 
			
		||||
   data type.  To create a binary-compatible cast, you must be superuser.
 | 
			
		||||
   (This restriction is made because an erroneous binary-compatible cast
 | 
			
		||||
   conversion can easily crash the server.)
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
   <variablelist>
 | 
			
		||||
    <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term><replaceable>sourcetype</replaceable></term>
 | 
			
		||||
 | 
			
		||||
@ -183,6 +185,21 @@ SELECT 'The time is ' || CAST(now() AS text);
 | 
			
		||||
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE CAST</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the cast was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="sql-createcast-notes">
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
@ -201,8 +218,8 @@ SELECT 'The time is ' || CAST(now() AS text);
 | 
			
		||||
   argument of a different type was automatically a cast function.
 | 
			
		||||
   This convention has been abandoned in face of the introduction of
 | 
			
		||||
   schemas and to be able to represent binary compatible casts in the
 | 
			
		||||
   catalogs.  (The built-in cast functions still follow this naming
 | 
			
		||||
   scheme, but they have to be shown as casts in <literal>pg_cast</>
 | 
			
		||||
   system catalogs.  (The built-in cast functions still follow this naming
 | 
			
		||||
   scheme, but they have to be shown as casts in the system catalog <literal>pg_cast</>
 | 
			
		||||
   now.)
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
@ -227,7 +244,7 @@ CREATE CAST (text AS int4) WITH FUNCTION int4(text);
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <command>CREATE CAST</command> command conforms to SQL99,
 | 
			
		||||
   except that SQL99 does not make provisions for binary compatible
 | 
			
		||||
   except that SQL99 does not make provisions for binary-compatible
 | 
			
		||||
   types.  <literal>AS IMPLICIT</> is a <productname>PostgreSQL</productname>
 | 
			
		||||
   extension, too.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_constraint.sgml,v 1.8 2002/05/18 15:44:47 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_constraint.sgml,v 1.9 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,30 +8,35 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createconstraint-title">CREATE CONSTRAINT TRIGGER</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE CONSTRAINT TRIGGER
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new constraint trigger
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE CONSTRAINT TRIGGER</refname>
 | 
			
		||||
  <refpurpose>define a new constraint trigger</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2000-04-13</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE CONSTRAINT TRIGGER <replaceable class="parameter">name</replaceable>
 | 
			
		||||
    AFTER <replaceable class="parameter">events</replaceable> ON
 | 
			
		||||
    <replaceable class="parameter">relation</replaceable> <replaceable class="parameter">constraint</replaceable> <replaceable class="parameter">attributes</replaceable>
 | 
			
		||||
    FOR EACH ROW EXECUTE PROCEDURE <replaceable class="parameter">func</replaceable> '(' <replaceable class="parameter">args</replaceable> ')'
 | 
			
		||||
  </synopsis>
 | 
			
		||||
    <replaceable class="parameter">table</replaceable> <replaceable class="parameter">constraint</replaceable> <replaceable class="parameter">attributes</replaceable>
 | 
			
		||||
    FOR EACH ROW EXECUTE PROCEDURE <replaceable class="parameter">func</replaceable> ( <replaceable class="parameter">args</replaceable> )
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATECONSTRAINT-1">
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE CONSTRAINT TRIGGER</command> is used within
 | 
			
		||||
   <command>CREATE TABLE</command>/<command>ALTER TABLE</command> and by
 | 
			
		||||
   <application>pg_dump</application>  to  create  the  special  triggers  for
 | 
			
		||||
   referential  integrity.
 | 
			
		||||
   It is not intended for general use.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
   <title>Parameters</title>
 | 
			
		||||
		
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
@ -53,10 +58,10 @@ CREATE CONSTRAINT TRIGGER <replaceable class="parameter">name</replaceable>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">relation</replaceable></term>
 | 
			
		||||
      <term><replaceable class="PARAMETER">table</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name (possibly schema-qualified) of the relation in which
 | 
			
		||||
	The name (possibly schema-qualified) of the table in which
 | 
			
		||||
	the triggering events occur.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
@ -75,7 +80,7 @@ CREATE CONSTRAINT TRIGGER <replaceable class="parameter">name</replaceable>
 | 
			
		||||
      <term><replaceable class="PARAMETER">attributes</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Constraint attributes.
 | 
			
		||||
	The constraint attributes.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -84,25 +89,19 @@ CREATE CONSTRAINT TRIGGER <replaceable class="parameter">name</replaceable>
 | 
			
		||||
      <term><replaceable class="PARAMETER">func</replaceable>(<replaceable class="PARAMETER">args</replaceable>)</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Function to call as part of the trigger processing.
 | 
			
		||||
	The function to call as part of the trigger processing.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATECONSTRAINT-2">
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
    
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE TRIGGER
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <term><computeroutput>CREATE TRIGGER</computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if successful.
 | 
			
		||||
@ -110,24 +109,6 @@ CREATE TRIGGER
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATECONSTRAINT-1">
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE CONSTRAINT TRIGGER</command> is used within
 | 
			
		||||
   <command>CREATE/ALTER TABLE</command> and by
 | 
			
		||||
   <application>pg_dump</application>  to  create  the  special  triggers  for
 | 
			
		||||
   referential  integrity.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   It is not intended for general use.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,4 +1,4 @@
 | 
			
		||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/create_conversion.sgml,v 1.7 2003/03/25 16:15:39 petere Exp $ -->
 | 
			
		||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/create_conversion.sgml,v 1.8 2003/04/22 10:08:08 petere Exp $ -->
 | 
			
		||||
 | 
			
		||||
<refentry id="SQL-CREATECONVERSION">
 | 
			
		||||
 <refmeta>
 | 
			
		||||
@ -23,21 +23,24 @@ CREATE [DEFAULT] CONVERSION <replaceable>conversion_name</replaceable>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE CONVERSION</command> defines a new encoding
 | 
			
		||||
   conversion.  Conversion names may be used in the CONVERT() function
 | 
			
		||||
   conversion.  Conversion names may be used in the <function>convert</function> function
 | 
			
		||||
   to specify a particular encoding conversion.  Also, conversions that
 | 
			
		||||
   are marked DEFAULT can be used for automatic encoding conversion between
 | 
			
		||||
   frontend and backend. For this purpose, two conversions, from encoding A to
 | 
			
		||||
   B AND from encoding B to A, must be defined.
 | 
			
		||||
   are marked <literal>DEFAULT</> can be used for automatic encoding conversion between
 | 
			
		||||
   client and server. For this purpose, two conversions, from encoding A to
 | 
			
		||||
   B <emphasis>and</emphasis> from encoding B to A, must be defined.
 | 
			
		||||
 </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To be able to create a conversion, you must have the execute right
 | 
			
		||||
   on the function and the create right on the destination schema.
 | 
			
		||||
   To be able to create a conversion, you must have <literal>EXECUTE</literal> privilege
 | 
			
		||||
   on the function and <literal>CREATE</literal> privilege on the destination schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
   <variablelist>
 | 
			
		||||
    <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term><literal>DEFAULT</literal></term>
 | 
			
		||||
 | 
			
		||||
@ -75,7 +78,7 @@ CREATE [DEFAULT] CONVERSION <replaceable>conversion_name</replaceable>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term><replaceable>source_encoding</replaceable></term>
 | 
			
		||||
     <term><replaceable>dest_encoding</replaceable></term>
 | 
			
		||||
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
@ -92,25 +95,39 @@ CREATE [DEFAULT] CONVERSION <replaceable>conversion_name</replaceable>
 | 
			
		||||
       The function used to perform the conversion.  The function name may
 | 
			
		||||
       be schema-qualified.  If it is not, the function will be looked
 | 
			
		||||
       up in the path.
 | 
			
		||||
       </para>
 | 
			
		||||
      </para>
 | 
			
		||||
 | 
			
		||||
       <para>
 | 
			
		||||
      <para>
 | 
			
		||||
       The function must have the following signature:
 | 
			
		||||
 | 
			
		||||
       <programlisting>
 | 
			
		||||
	conv_proc(
 | 
			
		||||
	INTEGER,	-- source encoding id
 | 
			
		||||
	INTEGER,	-- destination encoding id
 | 
			
		||||
	CSTRING,	-- source string (null terminated C string)
 | 
			
		||||
	CSTRING,	-- destination string (null terminated C string)
 | 
			
		||||
	INTEGER		-- source string length
 | 
			
		||||
	) returns VOID;
 | 
			
		||||
       </programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
conv_proc(
 | 
			
		||||
    integer,  -- source encoding ID
 | 
			
		||||
    integer,  -- destination encoding ID
 | 
			
		||||
    cstring,  -- source string (null terminated C string)
 | 
			
		||||
    cstring,  -- destination string (null terminated C string)
 | 
			
		||||
    integer   -- source string length
 | 
			
		||||
) RETURNS void;
 | 
			
		||||
</programlisting>
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
   </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE CONVERSION</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the conversion was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="sql-createconversion-notes">
 | 
			
		||||
@ -124,15 +141,14 @@ CREATE [DEFAULT] CONVERSION <replaceable>conversion_name</replaceable>
 | 
			
		||||
   The privileges required to create a conversion may be changed in a future
 | 
			
		||||
   release.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="sql-createconversion-examples">
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To create a conversion from encoding UNICODE to LATIN1 using <function>myfunc</>:
 | 
			
		||||
   To create a conversion from encoding <literal>UNICODE</literal> to
 | 
			
		||||
   <literal>LATIN1</literal> using <function>myfunc</>:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE CONVERSION myconv FOR 'UNICODE' TO 'LATIN1' FROM myfunc;
 | 
			
		||||
</programlisting>
 | 
			
		||||
@ -147,7 +163,7 @@ CREATE CONVERSION myconv FOR 'UNICODE' TO 'LATIN1' FROM myfunc;
 | 
			
		||||
    <command>CREATE CONVERSION</command>
 | 
			
		||||
    is a <productname>PostgreSQL</productname> extension.
 | 
			
		||||
    There is no <command>CREATE CONVERSION</command>
 | 
			
		||||
    statement in <acronym>SQL99</acronym>.
 | 
			
		||||
    statement in the SQL standard.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.33 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.34 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,34 +8,81 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createdatabase-title">CREATE DATABASE</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE DATABASE
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   create a new database
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE DATABASE</refname>
 | 
			
		||||
  <refpurpose>create a new database</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>1999-12-11</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
 | 
			
		||||
    [ [ WITH ] [ OWNER [=] <replaceable class="parameter">dbowner</replaceable> ]
 | 
			
		||||
           [ LOCATION [=] '<replaceable class="parameter">dbpath</replaceable>' ]
 | 
			
		||||
           [ TEMPLATE [=] <replaceable class="parameter">template</replaceable> ]
 | 
			
		||||
           [ ENCODING [=] <replaceable class="parameter">encoding</replaceable> ] ]
 | 
			
		||||
  </synopsis>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEDATABASE-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1999-12-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE DATABASE</command> creates a new
 | 
			
		||||
   <productname>PostgreSQL</productname> database.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Normally, the creator becomes the owner of the new database.
 | 
			
		||||
   Superusers can create databases owned by other users using the
 | 
			
		||||
   <literal>OWNER</> clause. They can even create databases owned by
 | 
			
		||||
   users with no special privileges. Non-superusers with <literal>CREATEDB</>
 | 
			
		||||
   privilege can only create databases owned by themselves.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   An alternative location can be specified in order to,
 | 
			
		||||
   for example, store the database on a different disk.
 | 
			
		||||
   The path must have been prepared with the 
 | 
			
		||||
   <xref linkend="APP-INITLOCATION" endterm="APP-INITLOCATION-title">
 | 
			
		||||
   command.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If the path name does not contain a slash, it is interpreted
 | 
			
		||||
   as an environment variable name, which must be known to the
 | 
			
		||||
   server process. This way the database administrator can
 | 
			
		||||
   exercise control over locations in which databases can be created.
 | 
			
		||||
   (A customary choice is, e.g., <envar>PGDATA2</envar>.)
 | 
			
		||||
   If the server is compiled with <literal>ALLOW_ABSOLUTE_DBPATHS</literal>
 | 
			
		||||
   (not so by default), absolute path names, as identified by
 | 
			
		||||
   a leading slash
 | 
			
		||||
   (e.g., <filename>/usr/local/pgsql/data</filename>),
 | 
			
		||||
   are allowed as well.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   By default, the new database will be created by cloning the standard
 | 
			
		||||
   system database <literal>template1</>.  A different template can be
 | 
			
		||||
   specified by writing <literal>TEMPLATE
 | 
			
		||||
   <replaceable class="parameter">name</replaceable></literal>.  In particular,
 | 
			
		||||
   by writing <literal>TEMPLATE template0</>, you can create a virgin
 | 
			
		||||
   database containing only the standard objects predefined by your
 | 
			
		||||
   version of <productname>PostgreSQL</productname>.  This is useful
 | 
			
		||||
   if you wish to avoid copying
 | 
			
		||||
   any installation-local objects that may have been added to
 | 
			
		||||
   <literal>template1</>. 
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The optional encoding parameter allows selection of the database
 | 
			
		||||
   encoding.  When not specified, it defaults to the encoding used by
 | 
			
		||||
   the selected template database.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameter</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
@ -50,7 +97,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
 | 
			
		||||
      <term><replaceable class="parameter">dbowner</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Name of the database user who will own the new database,
 | 
			
		||||
        The name of the database user who will own the new database,
 | 
			
		||||
	or <literal>DEFAULT</literal> to use the default (namely, the
 | 
			
		||||
	user executing the command).
 | 
			
		||||
       </para>
 | 
			
		||||
@ -70,7 +117,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
 | 
			
		||||
      <term><replaceable class="parameter">template</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Name of template from which to create the new database,
 | 
			
		||||
        The name of the template from which to create the new database,
 | 
			
		||||
	or <literal>DEFAULT</literal> to use the default template
 | 
			
		||||
	(<literal>template1</literal>).
 | 
			
		||||
       </para>
 | 
			
		||||
@ -80,32 +127,30 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
 | 
			
		||||
      <term><replaceable class="parameter">encoding</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Multibyte encoding method to use in the new database.  Specify
 | 
			
		||||
	a string literal name (e.g., <literal>'SQL_ASCII'</literal>),
 | 
			
		||||
        Character set encoding to use in the new database.  Specify
 | 
			
		||||
	a string constant (e.g., <literal>'SQL_ASCII'</literal>),
 | 
			
		||||
	or an integer encoding number, or <literal>DEFAULT</literal>
 | 
			
		||||
	to use the default encoding.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEDATABASE-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1999-12-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Optional parameters can be written in any order, not only the order
 | 
			
		||||
   illustrated above.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>CREATE DATABASE</computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the command completes successfully.
 | 
			
		||||
	Message returned if the database was successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -125,8 +170,8 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
 | 
			
		||||
      <term><computeroutput>ERROR:  createdb: database "<replaceable class="parameter">name</replaceable>" already exists</computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	This occurs if a database with the <replaceable class="parameter">name</replaceable>
 | 
			
		||||
        specified already exists.
 | 
			
		||||
	This occurs if a database with the specified name already
 | 
			
		||||
	exists.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -166,186 +211,73 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEDATABASE-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>1999-12-11</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE DATABASE</command> creates a new
 | 
			
		||||
   <productname>PostgreSQL</productname> database.
 | 
			
		||||
  </para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Normally, the creator becomes the owner of the new database.
 | 
			
		||||
   Superusers can create databases owned by other users using the
 | 
			
		||||
   <option>OWNER</> clause. They can even create databases owned by
 | 
			
		||||
   users with no special privileges. Non-superusers with <literal>CREATEDB</>
 | 
			
		||||
   privilege can only create databases owned by themselves.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   An alternate location can be specified in order to,
 | 
			
		||||
   for example, store the database on a different disk.
 | 
			
		||||
   The path must have been prepared with the 
 | 
			
		||||
   <xref linkend="APP-INITLOCATION" endterm="APP-INITLOCATION-title">
 | 
			
		||||
   command.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   If the path name does not contain a slash, it is interpreted
 | 
			
		||||
   as an environment variable name, which must be known to the
 | 
			
		||||
   server process. This way the database administrator can
 | 
			
		||||
   exercise control over locations in which databases can be created.
 | 
			
		||||
   (A customary choice is, e.g., <envar>PGDATA2</envar>.)
 | 
			
		||||
   If the server is compiled with <literal>ALLOW_ABSOLUTE_DBPATHS</literal>
 | 
			
		||||
   (not so by default), absolute path names, as identified by
 | 
			
		||||
   a leading slash
 | 
			
		||||
   (e.g., <filename>/usr/local/pgsql/data</filename>),
 | 
			
		||||
   are allowed as well.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   By default, the new database will be created by cloning the standard
 | 
			
		||||
   system database <literal>template1</>.  A different template can be
 | 
			
		||||
   specified by writing <literal>TEMPLATE =</>
 | 
			
		||||
   <replaceable class="parameter">name</replaceable>.  In particular,
 | 
			
		||||
   by writing <literal>TEMPLATE = template0</>, you can create a virgin
 | 
			
		||||
   database containing only the standard objects predefined by your
 | 
			
		||||
   version of <productname>PostgreSQL</productname>.  This is useful
 | 
			
		||||
   if you wish to avoid copying
 | 
			
		||||
   any installation-local objects that may have been added to
 | 
			
		||||
   <literal>template1</>. 
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The optional encoding parameter allows selection of the database
 | 
			
		||||
   encoding.  When not specified, it defaults to the encoding used by
 | 
			
		||||
   the selected template database.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Optional parameters can be written in any order, not only the order
 | 
			
		||||
   illustrated above.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEDATABASE-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1999-12-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE DATABASE</command> is a <productname>PostgreSQL</productname>
 | 
			
		||||
    language extension.
 | 
			
		||||
   </para>
 | 
			
		||||
   <para>
 | 
			
		||||
    Use <xref linkend="SQL-DROPDATABASE" endterm="SQL-DROPDATABASE-title"> to remove a database.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The program <xref linkend="APP-CREATEDB" endterm="APP-CREATEDB-title"> is a
 | 
			
		||||
    shell script wrapper around this command, provided for convenience.
 | 
			
		||||
    wrapper program around this command, provided for convenience.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    There are security and data integrity issues
 | 
			
		||||
    involved with using alternate database locations
 | 
			
		||||
    specified with absolute path names, and by default
 | 
			
		||||
    only an environment variable known to the backend may be
 | 
			
		||||
    specified for an alternate location.
 | 
			
		||||
    See <xref linkend="manage-ag-alternate-locs"> for more information.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
<!--
 | 
			
		||||
comment from Olly; response from Thomas...
 | 
			
		||||
  <comment>
 | 
			
		||||
   initlocation does not create a PG_VERSION file in the specified location.
 | 
			
		||||
   How will PostgreSQL handle the situation if it is upgraded to an 
 | 
			
		||||
   incompatible database version?
 | 
			
		||||
  </comment>
 | 
			
		||||
   Hmm. This isn't an issue since the upgrade would do
 | 
			
		||||
   a dump/reload from the main database area also.
 | 
			
		||||
   Not sure if the dump/reload would guarantee that
 | 
			
		||||
   the alternate data area gets refreshed though...
 | 
			
		||||
-->
 | 
			
		||||
  <para>
 | 
			
		||||
   There are security issues involved with using alternate database
 | 
			
		||||
   locations specified with absolute path names.  See <xref
 | 
			
		||||
   linkend="manage-ag-alternate-locs"> for more information.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Although it is possible to copy a database other than <literal>template1</>
 | 
			
		||||
   by specifying its name as the template, this is not (yet) intended as
 | 
			
		||||
   a general-purpose COPY DATABASE facility.
 | 
			
		||||
   a general-purpose <quote><command>COPY DATABASE</command></quote> facility.
 | 
			
		||||
   We recommend that databases used as templates be treated as read-only.
 | 
			
		||||
   See <xref linkend="user-manag"> for more information.
 | 
			
		||||
   See <xref linkend="manage-ag-templatedbs"> for more information.
 | 
			
		||||
  </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEDATABASE-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To create a new database:
 | 
			
		||||
 | 
			
		||||
   <programlisting>
 | 
			
		||||
<prompt>olly=></prompt> <userinput>create database lusiadas;</userinput>
 | 
			
		||||
   </programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE DATABASE lusiadas;
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To create a new database in an alternate area <filename>~/private_db</filename>:
 | 
			
		||||
   To create a new database in an alternate area
 | 
			
		||||
   <filename>~/private_db</filename>, execute the following from the
 | 
			
		||||
   shell:
 | 
			
		||||
 | 
			
		||||
   <programlisting>
 | 
			
		||||
<prompt>$</prompt> <userinput>mkdir private_db</userinput>
 | 
			
		||||
<prompt>$</prompt> <userinput>initlocation ~/private_db</userinput>
 | 
			
		||||
    <computeroutput>
 | 
			
		||||
The location will be initialized with username "olly".
 | 
			
		||||
This user will own all the files and must also own the server process.
 | 
			
		||||
Creating directory /home/olly/private_db
 | 
			
		||||
Creating directory /home/olly/private_db/base
 | 
			
		||||
<programlisting>
 | 
			
		||||
mkdir private_db
 | 
			
		||||
initlocation ~/private_db
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
initlocation is complete.
 | 
			
		||||
    </computeroutput>
 | 
			
		||||
   
 | 
			
		||||
<prompt>$</prompt> <userinput>psql olly</userinput>
 | 
			
		||||
<computeroutput>
 | 
			
		||||
Welcome to psql, the PostgreSQL interactive terminal.
 | 
			
		||||
 
 | 
			
		||||
Type:  \copyright for distribution terms
 | 
			
		||||
       \h for help with SQL commands
 | 
			
		||||
       \? for help on internal slash commands
 | 
			
		||||
       \g or terminate with semicolon to execute query
 | 
			
		||||
       \q to quit
 | 
			
		||||
   Then execute the following from within a
 | 
			
		||||
   <application>psql</application> session:
 | 
			
		||||
 | 
			
		||||
<prompt>olly=></prompt></computeroutput> <userinput>CREATE DATABASE elsewhere WITH LOCATION = '/home/olly/private_db';</userinput>
 | 
			
		||||
<computeroutput>CREATE DATABASE</computeroutput>
 | 
			
		||||
   </programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE DATABASE elsewhere WITH LOCATION '/home/olly/private_db';
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEDATABASE-4">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEDATABASE-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-04-15</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    There is no <command>CREATE DATABASE</command> statement in SQL92.
 | 
			
		||||
    Databases are equivalent to catalogs, whose creation is
 | 
			
		||||
    implementation-defined.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   There is no <command>CREATE DATABASE</command> statement in the SQL
 | 
			
		||||
   standard.  Databases are equivalent to catalogs, whose creation is
 | 
			
		||||
   implementation-defined.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,28 +1,21 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_domain.sgml,v 1.12 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_domain.sgml,v 1.13 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
<refentry id="SQL-CREATEDOMAIN">
 | 
			
		||||
 <refmeta>
 | 
			
		||||
  <refentrytitle id="sql-createdomain-title">
 | 
			
		||||
   CREATE DOMAIN
 | 
			
		||||
  </refentrytitle>
 | 
			
		||||
  <refentrytitle id="sql-createdomain-title">CREATE DOMAIN</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE DOMAIN
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new domain
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE DOMAIN</refname>
 | 
			
		||||
  <refpurpose>define a new domain</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2002-02-24</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE DOMAIN <replaceable class="parameter">domainname</replaceable> [AS] <replaceable class="parameter">data_type</replaceable>
 | 
			
		||||
    [ DEFAULT <replaceable>default_expr</> ]
 | 
			
		||||
    [ <replaceable class="PARAMETER">constraint</replaceable> [ ... ] ]
 | 
			
		||||
@ -31,16 +24,35 @@ where <replaceable class="PARAMETER">constraint</replaceable> is:
 | 
			
		||||
 | 
			
		||||
[ CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> ]
 | 
			
		||||
{ NOT NULL | NULL | CHECK (<replaceable class="PARAMETER">expression</replaceable>) }
 | 
			
		||||
  </synopsis>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEDOMAIN-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2002-02-24</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Parameters
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE DOMAIN</command> creates a new data domain.  The
 | 
			
		||||
   user who defines a domain becomes its owner.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given (for example, <literal>CREATE DOMAIN
 | 
			
		||||
   myschema.mydomain ...</>) then the domain is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
   The domain name must be unique among the types and domains existing
 | 
			
		||||
   in its schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Domains are useful for abstracting common fields between tables into
 | 
			
		||||
   a single location for maintenance.  For example, an email address column may be used
 | 
			
		||||
   in several tables, all with the same properties.  Define a domain and
 | 
			
		||||
   use that rather than setting up each table's constraints individually.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
@ -63,32 +75,26 @@ where <replaceable class="PARAMETER">constraint</replaceable> is:
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><literal>DEFAULT
 | 
			
		||||
      <replaceable>default_expr</replaceable></literal></term>
 | 
			
		||||
      <term><literal>DEFAULT <replaceable>default_expr</replaceable></literal></term>
 | 
			
		||||
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The <literal>DEFAULT</> clause specifies a default value for
 | 
			
		||||
	columns of the domain data type.  The value
 | 
			
		||||
        is any variable-free expression (but subselects are not allowed).
 | 
			
		||||
	The
 | 
			
		||||
        data type of the default expression must match the data type of the
 | 
			
		||||
        domain.
 | 
			
		||||
        columns of the domain data type.  The value is any
 | 
			
		||||
        variable-free expression (but subqueries are not allowed).
 | 
			
		||||
        The data type of the default expression must match the data
 | 
			
		||||
        type of the domain.  If no default value is specified, then
 | 
			
		||||
        the default value is the null value.
 | 
			
		||||
       </para>
 | 
			
		||||
 | 
			
		||||
       <para>
 | 
			
		||||
        The default expression will be used in any insert operation that
 | 
			
		||||
        does not specify a value for the column.  If there is no default
 | 
			
		||||
        for a domain, then the default is NULL.
 | 
			
		||||
        The default expression will be used in any insert operation
 | 
			
		||||
        that does not specify a value for the column.  If a default
 | 
			
		||||
        value is defined for a particular column, it overrides any
 | 
			
		||||
        default associated with the domain.  In turn, the domain
 | 
			
		||||
        default overrides any default value associated with the
 | 
			
		||||
        underlying data type.
 | 
			
		||||
       </para>
 | 
			
		||||
 | 
			
		||||
       <note>
 | 
			
		||||
        <para>
 | 
			
		||||
         If a default value is specified for a particular column, it
 | 
			
		||||
	 overrides any default associated with the domain.  In turn,
 | 
			
		||||
	 the domain default overrides any default value associated with
 | 
			
		||||
	 the underlying data type.
 | 
			
		||||
        </para>
 | 
			
		||||
       </note>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
@ -106,7 +112,7 @@ where <replaceable class="PARAMETER">constraint</replaceable> is:
 | 
			
		||||
      <term><literal>NOT NULL</></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Values of this domain are not allowed to be NULL.  
 | 
			
		||||
        Values of this domain are not allowed to be null.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -115,12 +121,12 @@ where <replaceable class="PARAMETER">constraint</replaceable> is:
 | 
			
		||||
      <term><literal>NULL</></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Values of this domain are allowed to be NULL.  This is the default.
 | 
			
		||||
        Values of this domain are allowed to be null.  This is the default.
 | 
			
		||||
       </para>
 | 
			
		||||
 | 
			
		||||
       <para>
 | 
			
		||||
        This clause is only available for compatibility with
 | 
			
		||||
        non-standard SQL databases.  Its use is discouraged in new
 | 
			
		||||
        This clause is only intended for compatibility with
 | 
			
		||||
        nonstandard SQL databases.  Its use is discouraged in new
 | 
			
		||||
        applications.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
@ -139,84 +145,50 @@ where <replaceable class="PARAMETER">constraint</replaceable> is:
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      Currently, <literal>CHECK</literal> expressions cannot contain
 | 
			
		||||
      subselects nor refer to variables other than <literal>VALUE</>.
 | 
			
		||||
      subqueries nor refer to variables other than <literal>VALUE</>.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEDOMAIN-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2002-02-24</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE DOMAIN
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the domain is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEDOMAIN-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2002-02-24</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE DOMAIN</command>  allows  the user to register a new
 | 
			
		||||
   data domain with <productname>PostgreSQL</> for use in the
 | 
			
		||||
   current data base.   The user  who  defines  a domain becomes its owner.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given (for example, <literal>CREATE DOMAIN
 | 
			
		||||
   myschema.mydomain ...</>) then the domain is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   The domain name must be unique among the types and domains existing
 | 
			
		||||
   in its schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Domains are useful for abstracting common fields between tables into
 | 
			
		||||
   a single location for maintenance.  An email address column may be used
 | 
			
		||||
   in several tables, all with the same properties.  Define a domain and
 | 
			
		||||
   use that rather than setting up each table's constraints individually.
 | 
			
		||||
  </para>
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE DOMAIN</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the domain was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   This example creates the <type>country_code</type> data type and then uses the
 | 
			
		||||
   type in a table definition:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE DOMAIN country_code char(2) NOT NULL;
 | 
			
		||||
CREATE TABLE countrylist (id INT4, country country_code);
 | 
			
		||||
CREATE TABLE countrylist (id integer, country country_code);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="SQL-CREATEDOMAIN-compatibility">
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The command <command>CREATE DOMAIN</command> conforms to the SQL
 | 
			
		||||
   standard.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="SQL-CREATEDOMAIN-see-also">
 | 
			
		||||
  <title>See Also</title>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_function.sgml,v 1.46 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_function.sgml,v 1.47 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
<refentry id="SQL-CREATEFUNCTION">
 | 
			
		||||
@ -38,25 +38,48 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The user that creates the function becomes the owner of the function.
 | 
			
		||||
   If a schema name is included, then the function is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
   The name of the new function must not match any existing function
 | 
			
		||||
   with the same argument types in the same schema.  However,
 | 
			
		||||
   functions of different argument types may share a name (this is
 | 
			
		||||
   called <firstterm>overloading</>).
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To update the definition of an existing function, use
 | 
			
		||||
   <command>CREATE OR REPLACE FUNCTION</command>.  It is not possible
 | 
			
		||||
   to change the name or argument types of a function this way (if you
 | 
			
		||||
   tried, you'd just be creating a new, distinct function).  Also,
 | 
			
		||||
   <command>CREATE OR REPLACE FUNCTION</command> will not let you
 | 
			
		||||
   change the return type of an existing function.  To do that, you
 | 
			
		||||
   must drop and recreate the function.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If you drop and then recreate a function, the new function is not
 | 
			
		||||
   the same entity as the old; you will break existing rules, views,
 | 
			
		||||
   triggers, etc. that referred to the old function.  Use
 | 
			
		||||
   <command>CREATE OR REPLACE FUNCTION</command> to change a function
 | 
			
		||||
   definition without breaking objects that refer to the function.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The user that creates the function becomes the owner of the function.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
   <variablelist>
 | 
			
		||||
    <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       The name of a function to create.  If a schema name is included,
 | 
			
		||||
       then the function is created in the
 | 
			
		||||
       specified schema.  Otherwise it is created in the current schema (the
 | 
			
		||||
       one at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
       The name of the new function must not match any existing function
 | 
			
		||||
       with the same argument types in the same schema.  However, functions of
 | 
			
		||||
       different argument types may share a name (this is called
 | 
			
		||||
       <firstterm>overloading</>).
 | 
			
		||||
       The name of a function to create.
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
@ -67,20 +90,21 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       The data type(s) of the function's arguments (optionally 
 | 
			
		||||
       schema-qualified), if any. The input types may be base, complex, or 
 | 
			
		||||
       domain types, or the same as the type of an existing column.
 | 
			
		||||
       schema-qualified), if any. The argument types may be base, complex, or 
 | 
			
		||||
       domain types, or copy the type of an existing column.
 | 
			
		||||
      </para>
 | 
			
		||||
      <para>
 | 
			
		||||
       The type of a column is referenced by writing <replaceable
 | 
			
		||||
       The type of a column is referenced by writing
 | 
			
		||||
       <literal><replaceable
 | 
			
		||||
       class="parameter">tablename</replaceable>.<replaceable
 | 
			
		||||
       class="parameter">columnname</replaceable><literal>%TYPE</literal>;
 | 
			
		||||
       class="parameter">columnname</replaceable>%TYPE</literal>;
 | 
			
		||||
       using this can sometimes help make a function independent from
 | 
			
		||||
       changes to the definition of a table.
 | 
			
		||||
      </para>
 | 
			
		||||
      <para>
 | 
			
		||||
       Depending on the implementation language it may also be allowed
 | 
			
		||||
       to specify <quote>pseudo-types</> such as <type>cstring</>.
 | 
			
		||||
       Pseudo-types indicate that the actual argument type is either
 | 
			
		||||
       to specify <quote>pseudotypes</> such as <type>cstring</>.
 | 
			
		||||
       Pseudotypes indicate that the actual argument type is either
 | 
			
		||||
       incompletely specified, or outside the set of ordinary SQL data types.
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
@ -92,15 +116,15 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       The return data type (optionally schema-qualified). The return type 
 | 
			
		||||
       may be specified as a base, complex, domain type 
 | 
			
		||||
       or the same as the type of an existing column. See the description
 | 
			
		||||
       may be specified as a base, complex, or domain type,
 | 
			
		||||
       or may copy the type of an existing column. See the description
 | 
			
		||||
       under <literal>argtype</literal> above on how to reference the type
 | 
			
		||||
       of an existing column.
 | 
			
		||||
      </para>
 | 
			
		||||
      <para>
 | 
			
		||||
       Depending on the implementation language it may also be allowed
 | 
			
		||||
       to specify <quote>pseudo-types</> such as <type>cstring</>.
 | 
			
		||||
       The <literal>setof</literal>
 | 
			
		||||
       to specify <quote>pseudotypes</> such as <type>cstring</>.
 | 
			
		||||
       The <literal>SETOF</literal>
 | 
			
		||||
       modifier indicates that the function will return a set of
 | 
			
		||||
       items, rather than a single item.
 | 
			
		||||
      </para>
 | 
			
		||||
@ -123,9 +147,9 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term>IMMUTABLE</term>
 | 
			
		||||
     <term>STABLE</term>
 | 
			
		||||
     <term>VOLATILE</term>
 | 
			
		||||
     <term><literal>IMMUTABLE</literal></term>
 | 
			
		||||
     <term><literal>STABLE</literal></term>
 | 
			
		||||
     <term><literal>VOLATILE</literal></term>
 | 
			
		||||
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
@ -140,7 +164,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
       <literal>IMMUTABLE</literal> indicates that the function always
 | 
			
		||||
       returns the same result when given the same argument values; that
 | 
			
		||||
       is, it does not do database lookups or otherwise use information not
 | 
			
		||||
       directly present in its parameter list.  If this option is given,
 | 
			
		||||
       directly present in its argument list.  If this option is given,
 | 
			
		||||
       any call of the function with all-constant arguments can be
 | 
			
		||||
       immediately replaced with the function value.
 | 
			
		||||
      </para>
 | 
			
		||||
@ -152,7 +176,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
       result could change across SQL statements.  This is the appropriate
 | 
			
		||||
       selection for functions whose results depend on database lookups,
 | 
			
		||||
       parameter variables (such as the current time zone), etc.  Also note
 | 
			
		||||
       that the <literal>CURRENT_TIMESTAMP</> family of functions qualify
 | 
			
		||||
       that the <function>current_timestamp</> family of functions qualify
 | 
			
		||||
       as stable, since their values do not change within a transaction.
 | 
			
		||||
      </para>
 | 
			
		||||
 | 
			
		||||
@ -170,9 +194,9 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term>CALLED ON NULL INPUT</term>
 | 
			
		||||
     <term>RETURNS NULL ON NULL INPUT</term>
 | 
			
		||||
     <term>STRICT</term>
 | 
			
		||||
     <term><literal>CALLED ON NULL INPUT</literal></term>
 | 
			
		||||
     <term><literal>RETURNS NULL ON NULL INPUT</literal></term>
 | 
			
		||||
     <term><literal>STRICT</literal></term>
 | 
			
		||||
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
@ -186,17 +210,17 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
      <para>
 | 
			
		||||
       <literal>RETURNS NULL ON NULL INPUT</literal> or
 | 
			
		||||
       <literal>STRICT</literal> indicates that the function always
 | 
			
		||||
       returns NULL whenever any of its arguments are NULL.  If this
 | 
			
		||||
       returns null whenever any of its arguments are null.  If this
 | 
			
		||||
       parameter is specified, the function is not executed when there
 | 
			
		||||
       are NULL arguments; instead a NULL result is assumed
 | 
			
		||||
       are null arguments; instead a null result is assumed
 | 
			
		||||
       automatically.
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><optional>EXTERNAL</optional> SECURITY INVOKER</term>
 | 
			
		||||
    <term><optional>EXTERNAL</optional> SECURITY DEFINER</term>
 | 
			
		||||
    <term><literal><optional>EXTERNAL</optional> SECURITY INVOKER</literal></term>
 | 
			
		||||
    <term><literal><optional>EXTERNAL</optional> SECURITY DEFINER</literal></term>
 | 
			
		||||
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
@ -209,7 +233,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      The key word <literal>EXTERNAL</literal> is present for SQL
 | 
			
		||||
      compatibility but is optional since, unlike in SQL, this feature
 | 
			
		||||
      conformance but is optional since, unlike in SQL, this feature
 | 
			
		||||
      does not only apply to external functions.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
@ -222,25 +246,26 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
      <para>
 | 
			
		||||
       A string defining the function; the meaning depends on the
 | 
			
		||||
       language.  It may be an internal function name, the path to an
 | 
			
		||||
       object file, an SQL query, or text in a procedural language.
 | 
			
		||||
       object file, an SQL command, or text in a procedural language.
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term><replaceable class="parameter">obj_file</replaceable>, <replaceable class="parameter">link_symbol</replaceable></term>
 | 
			
		||||
     <term><literal><replaceable class="parameter">obj_file</replaceable>, <replaceable class="parameter">link_symbol</replaceable></literal></term>
 | 
			
		||||
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       This form of the <literal>AS</literal> clause is used for
 | 
			
		||||
       dynamically linked C language functions when the function name
 | 
			
		||||
       dynamically loadable C language functions when the function name
 | 
			
		||||
       in the C language source code is not the same as the name of
 | 
			
		||||
       the SQL function. The string <replaceable
 | 
			
		||||
       class="parameter">obj_file</replaceable> is the name of the
 | 
			
		||||
       file containing the dynamically loadable object, and
 | 
			
		||||
       <replaceable class="parameter">link_symbol</replaceable> is the
 | 
			
		||||
       object's link symbol, that is, the name of the function in the C
 | 
			
		||||
       language source code.
 | 
			
		||||
       function's link symbol, that is, the name of the function in the C
 | 
			
		||||
       language source code.  If the link symbol is omitted, it is assumed
 | 
			
		||||
       to be the same as the name of the SQL function being defined.
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
@ -285,48 +310,47 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE FUNCTION</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the function was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="sql-createfunction-notes">
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Refer to <xref linkend="xfunc"> for further information on writing
 | 
			
		||||
    external functions.
 | 
			
		||||
    functions.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The full <acronym>SQL</acronym> type syntax is allowed for
 | 
			
		||||
    input arguments and return value. However, some details of the
 | 
			
		||||
    type specification (e.g., the precision field for
 | 
			
		||||
    <type>numeric</type> types) are the responsibility of the
 | 
			
		||||
    type <type>numeric</type>) are the responsibility of the
 | 
			
		||||
    underlying function implementation and are silently swallowed
 | 
			
		||||
    (i.e., not recognized or
 | 
			
		||||
    enforced) by the <command>CREATE FUNCTION</command> command.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <productname>PostgreSQL</productname> allows function <firstterm>overloading</firstterm>;
 | 
			
		||||
    that is, the same name can be used for several different functions
 | 
			
		||||
    so long as they have distinct argument types.  This facility must
 | 
			
		||||
    be used with caution for internal and C-language functions, however.    
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Two <literal>internal</literal>
 | 
			
		||||
    functions cannot have the same C name without causing
 | 
			
		||||
    errors at link time.  To get around that, give them different C names
 | 
			
		||||
    (for example, use the argument types as part of the C names), then
 | 
			
		||||
    specify those names in the AS clause of <command>CREATE FUNCTION</command>.
 | 
			
		||||
    If the AS clause is left empty, then <command>CREATE FUNCTION</command>
 | 
			
		||||
    assumes the C name of the function is the same as the SQL name.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Similarly, when overloading SQL function names with multiple C-language
 | 
			
		||||
    functions, give
 | 
			
		||||
    each C-language instance of the function a distinct name, then use
 | 
			
		||||
    the alternative form of the <command>AS</command> clause in the
 | 
			
		||||
    <command>CREATE FUNCTION</command> syntax to select the appropriate
 | 
			
		||||
    C-language implementation of each overloaded SQL function.
 | 
			
		||||
    <productname>PostgreSQL</productname> allows function
 | 
			
		||||
    <firstterm>overloading</firstterm>; that is, the same name can be
 | 
			
		||||
    used for several different functions so long as they have distinct
 | 
			
		||||
    argument types.  However, the C names of all functions must be
 | 
			
		||||
    different, so you must give overloaded C functions different C
 | 
			
		||||
    names (for example, use the argument types as part of the C
 | 
			
		||||
    names).
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
@ -341,116 +365,26 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
 | 
			
		||||
    to remove user-defined functions.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    To update the definition of an existing function, use
 | 
			
		||||
    <command>CREATE OR REPLACE FUNCTION</command>.  Note that it is
 | 
			
		||||
    not possible to change the name or argument types of a function
 | 
			
		||||
    this way (if you tried, you'd just be creating a new, distinct
 | 
			
		||||
    function).  Also, <command>CREATE OR REPLACE FUNCTION</command>
 | 
			
		||||
    will not let you change the return type of an existing function.
 | 
			
		||||
    To do that, you must drop and re-create the function.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    If you drop and then re-create a function, the new function is not
 | 
			
		||||
    the same entity as the old; you will break existing rules, views,
 | 
			
		||||
    triggers, etc that referred to the old function.  Use 
 | 
			
		||||
    <command>CREATE OR REPLACE FUNCTION</command> to change a function
 | 
			
		||||
    definition without breaking objects that refer to the function.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To be able to define a function, the user must have the
 | 
			
		||||
   <literal>USAGE</literal> privilege on the language.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   By default, only the owner (creator) of the function has the right
 | 
			
		||||
   to execute it.  Other users must be granted the
 | 
			
		||||
   <literal>EXECUTE</literal> privilege on the function to be able to
 | 
			
		||||
   use it.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="sql-createfunction-examples">
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To create a simple SQL function:
 | 
			
		||||
 | 
			
		||||
   Here is a trivial example to help you get startet.  For more
 | 
			
		||||
   information and examples, see <xref linkend="xfunc">.
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE FUNCTION one() RETURNS integer
 | 
			
		||||
    AS 'SELECT 1 AS RESULT;'
 | 
			
		||||
    LANGUAGE SQL;
 | 
			
		||||
 | 
			
		||||
SELECT one() AS answer;
 | 
			
		||||
<computeroutput>
 | 
			
		||||
 answer 
 | 
			
		||||
--------
 | 
			
		||||
      1
 | 
			
		||||
</computeroutput>
 | 
			
		||||
CREATE FUNCTION add(integer, integer) RETURNS integer
 | 
			
		||||
    AS 'select $1 + $2;'
 | 
			
		||||
    LANGUAGE SQL
 | 
			
		||||
    IMMUTABLE
 | 
			
		||||
    RETURNS NULL ON NULL INPUT;
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The next example creates a C function by calling a routine from a
 | 
			
		||||
   user-created shared library named <filename>funcs.so</> (the extension
 | 
			
		||||
   may vary across platforms).  The shared library file is sought in the
 | 
			
		||||
   server's dynamic library search path.  This particular routine calculates
 | 
			
		||||
   a check digit and returns true if the check digit in the function
 | 
			
		||||
   parameters is correct.  It is intended for use in a CHECK
 | 
			
		||||
   constraint.
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE FUNCTION ean_checkdigit(char, char) RETURNS boolean
 | 
			
		||||
    AS 'funcs' LANGUAGE C;
 | 
			
		||||
    
 | 
			
		||||
CREATE TABLE product (
 | 
			
		||||
    id        char(8) PRIMARY KEY,
 | 
			
		||||
    eanprefix char(8) CHECK (eanprefix ~ '[0-9]{2}-[0-9]{5}')
 | 
			
		||||
                      REFERENCES brandname(ean_prefix),
 | 
			
		||||
    eancode   char(6) CHECK (eancode ~ '[0-9]{6}'),
 | 
			
		||||
    CONSTRAINT ean    CHECK (ean_checkdigit(eanprefix, eancode))
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The next example creates a function that does type conversion from the
 | 
			
		||||
   user-defined type complex to the built-in type point.  The
 | 
			
		||||
   function is implemented by a dynamically loaded object that was
 | 
			
		||||
   compiled from C source (we illustrate the now-deprecated alternative
 | 
			
		||||
   of specifying the absolute file name to the shared object file).
 | 
			
		||||
   For <productname>PostgreSQL</productname> to
 | 
			
		||||
   find a type conversion function automatically, the SQL function has
 | 
			
		||||
   to have the same name as the return type, and so overloading is
 | 
			
		||||
   unavoidable.  The function name is overloaded by using the second
 | 
			
		||||
   form of the <command>AS</command> clause in the SQL definition:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE FUNCTION point(complex) RETURNS point
 | 
			
		||||
    AS '/home/bernie/pgsql/lib/complex.so', 'complex_to_point'
 | 
			
		||||
    LANGUAGE C STRICT;
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
  The C declaration of the function could be:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
Point * complex_to_point (Complex *z)
 | 
			
		||||
{
 | 
			
		||||
    Point *p;
 | 
			
		||||
 | 
			
		||||
    p = (Point *) palloc(sizeof(Point));
 | 
			
		||||
    p->x = z->x;
 | 
			
		||||
    p->y = z->y;
 | 
			
		||||
        
 | 
			
		||||
    return p;
 | 
			
		||||
}
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
   Note that the function is marked <quote>strict</>; this allows us
 | 
			
		||||
   to skip checking for NULL input in the function body.
 | 
			
		||||
  </para>    
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_group.sgml,v 1.10 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_group.sgml,v 1.11 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,35 +8,41 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-creategroup-title">CREATE GROUP</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE GROUP
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new user group
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE GROUP</refname>
 | 
			
		||||
  <refpurpose>define a new user group</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2000-01-14</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE GROUP <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replaceable class="PARAMETER">option</replaceable> [ ... ] ]
 | 
			
		||||
 | 
			
		||||
where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
 | 
			
		||||
     SYSID <replaceable class="PARAMETER">gid</replaceable>
 | 
			
		||||
   | USER  <replaceable class="PARAMETER">username</replaceable> [, ...]
 | 
			
		||||
  </synopsis>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE GROUP</command> will create a new group in the
 | 
			
		||||
   database cluster.  You must be a database
 | 
			
		||||
   superuser to use this command.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <xref linkend="SQL-ALTERGROUP" endterm="SQL-ALTERGROUP-title">
 | 
			
		||||
   to change a group's membership, and <xref linkend="SQL-DROPGROUP"
 | 
			
		||||
   endterm="SQL-DROPGROUP-title"> to remove a group.
 | 
			
		||||
  </para>  
 | 
			
		||||
 </refsect1> 
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEGROUP-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-01-14</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
@ -53,11 +59,11 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The <literal>SYSID</literal> clause can be used to choose
 | 
			
		||||
        the <productname>PostgreSQL</productname> group id of the new
 | 
			
		||||
        the <productname>PostgreSQL</productname> group ID of the new
 | 
			
		||||
        group. It is not necessary to do so, however.
 | 
			
		||||
       </para>
 | 
			
		||||
       <para>
 | 
			
		||||
        If this is not specified, the highest assigned group id plus one,
 | 
			
		||||
        If this is not specified, the highest assigned group ID plus one,
 | 
			
		||||
        starting at 1, will be used as default.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
@ -73,54 +79,26 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEGROUP-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-01-14</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>CREATE GROUP</computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the command completes successfully.
 | 
			
		||||
	Message returned if the group was successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEGROUP-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2000-01-14</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE GROUP</command> will create a new group in the
 | 
			
		||||
   database installation.  You must be a database
 | 
			
		||||
   superuser to use this command.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <xref linkend="SQL-ALTERGROUP" endterm="SQL-ALTERGROUP-title">
 | 
			
		||||
   to change a group's membership, and <xref linkend="SQL-DROPGROUP"
 | 
			
		||||
   endterm="SQL-DROPGROUP-title"> to remove a group.
 | 
			
		||||
  </para>  
 | 
			
		||||
 </refsect1> 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEGROUP-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   Create an empty group:
 | 
			
		||||
<programlisting>
 | 
			
		||||
@ -136,24 +114,13 @@ CREATE GROUP marketing WITH USER jonathan, david;
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEGROUP-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEGROUP-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-01-14</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    There is no <command>CREATE GROUP</command> statement in SQL92.
 | 
			
		||||
    Roles are similar in concept to groups.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   There is no <command>CREATE GROUP</command> statement in the SQL
 | 
			
		||||
   standard.  Roles are similar in concept to groups.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.37 2002/09/21 18:32:54 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.38 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,39 +8,101 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createindex-title">CREATE INDEX</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE INDEX
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new index
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2001-07-15</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable> ON <replaceable class="parameter">table</replaceable>
 | 
			
		||||
    [ USING <replaceable class="parameter">acc_method</replaceable> ] ( <replaceable class="parameter">column</replaceable> [ <replaceable class="parameter">ops_name</replaceable> ] [, ...] )
 | 
			
		||||
    [ WHERE <replaceable class="parameter">predicate</replaceable> ]
 | 
			
		||||
CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable> ON <replaceable class="parameter">table</replaceable>
 | 
			
		||||
    [ USING <replaceable class="parameter">acc_method</replaceable> ] ( <replaceable class="parameter">func_name</replaceable>( <replaceable class="parameter">column</replaceable> [, ... ]) [ <replaceable class="parameter">ops_name</replaceable> ] )
 | 
			
		||||
    [ WHERE <replaceable class="parameter">predicate</replaceable> ]
 | 
			
		||||
  </synopsis>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEINDEX-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-09</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>CREATE INDEX</refname>
 | 
			
		||||
  <refpurpose>define a new index</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable> ON <replaceable class="parameter">table</replaceable>
 | 
			
		||||
    [ USING <replaceable class="parameter">method</replaceable> ] ( <replaceable class="parameter">column</replaceable> [ <replaceable class="parameter">ops_name</replaceable> ] [, ...] )
 | 
			
		||||
    [ WHERE <replaceable class="parameter">predicate</replaceable> ]
 | 
			
		||||
 | 
			
		||||
CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable> ON <replaceable class="parameter">table</replaceable>
 | 
			
		||||
    [ USING <replaceable class="parameter">method</replaceable> ] ( <replaceable class="parameter">func_name</replaceable>( <replaceable class="parameter">column</replaceable> [, ... ]) [ <replaceable class="parameter">ops_name</replaceable> ] )
 | 
			
		||||
    [ WHERE <replaceable class="parameter">predicate</replaceable> ]
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE INDEX</command> constructs an index <replaceable
 | 
			
		||||
   class="parameter">index_name</replaceable> on the specified table.
 | 
			
		||||
   Indexes are primarily used to enhance database performance.  But
 | 
			
		||||
   inappropriate use will result in slower performance.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   In the first syntax shown above, the key field(s) for the
 | 
			
		||||
   index are specified as column names.
 | 
			
		||||
   Multiple fields can be specified if the index method supports
 | 
			
		||||
   multicolumn indexes.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   In the second syntax shown above, an index is defined on the result
 | 
			
		||||
   of a user-specified function <replaceable
 | 
			
		||||
   class="parameter">func_name</replaceable> applied to one or more
 | 
			
		||||
   columns of a single table. These <firstterm>functional
 | 
			
		||||
   indexes</firstterm> can be used to obtain fast access to data based
 | 
			
		||||
   on operators that would normally require some transformation to apply
 | 
			
		||||
   them to the base data. For example, a functional index on
 | 
			
		||||
   <literal>upper(col)</> would allow the clause
 | 
			
		||||
   <literal>WHERE upper(col) = 'JIM'</> to use an index.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <application>PostgreSQL</application> provides the index methods
 | 
			
		||||
   B-tree, R-tree, hash, and GiST. The B-tree index method is an
 | 
			
		||||
   implementation of Lehman-Yao high-concurrency B-trees. The R-tree
 | 
			
		||||
   index method implements standard R-trees using Guttman's quadratic
 | 
			
		||||
   split algorithm. The hash index method is an implementation of
 | 
			
		||||
   Litwin's linear hashing.  Users can also define their own index
 | 
			
		||||
   methods, but that is fairly complicated.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
    When the <literal>WHERE</literal> clause is present, a
 | 
			
		||||
    <firstterm>partial index</firstterm> is created.
 | 
			
		||||
    A partial index is an index that contains entries for only a portion of
 | 
			
		||||
    a table, usually a portion that is somehow more interesting than the
 | 
			
		||||
    rest of the table. For example, if you have a table that contains both
 | 
			
		||||
    billed and unbilled orders where the unbilled orders take up a small
 | 
			
		||||
    fraction of the total table and yet that is an often used section, you
 | 
			
		||||
    can improve performance by creating an index on just that portion.
 | 
			
		||||
    Another possible application is to use <literal>WHERE</literal> with
 | 
			
		||||
    <literal>UNIQUE</literal> to enforce uniqueness over a subset of a
 | 
			
		||||
    table.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
    The expression used in the <literal>WHERE</literal> clause may refer
 | 
			
		||||
    only to columns of the underlying table (but it can use all columns,
 | 
			
		||||
    not only the one(s) being indexed).  Presently, subqueries and
 | 
			
		||||
    aggregate expressions are also forbidden in <literal>WHERE</literal>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   All functions and operators used in an index definition must be
 | 
			
		||||
   <quote>immutable</>, that is, their results must depend only on
 | 
			
		||||
   their arguments and never on any outside influence (such as
 | 
			
		||||
   the contents of another table or the current time).  This restriction
 | 
			
		||||
   ensures that the behavior of the index is well-defined.  To use a
 | 
			
		||||
   user-defined function in an index, remember to mark the function immutable
 | 
			
		||||
   when you create it.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>UNIQUE</term>
 | 
			
		||||
      <term><literal>UNIQUE</literal></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Causes the system to check for
 | 
			
		||||
@ -73,52 +135,13 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">acc_method</replaceable></term>
 | 
			
		||||
      <term><replaceable class="parameter">method</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of the access method to be used for the index. The
 | 
			
		||||
	default access method is <literal>BTREE</literal>.
 | 
			
		||||
	<application>PostgreSQL</application> provides four access
 | 
			
		||||
	methods for indexes:
 | 
			
		||||
 | 
			
		||||
	<variablelist>
 | 
			
		||||
	 <varlistentry>
 | 
			
		||||
	  <term><literal>BTREE</></term>
 | 
			
		||||
	  <listitem>
 | 
			
		||||
	   <para>
 | 
			
		||||
	    an implementation of Lehman-Yao
 | 
			
		||||
	    high-concurrency B-trees.
 | 
			
		||||
	   </para>
 | 
			
		||||
	  </listitem>
 | 
			
		||||
	 </varlistentry>
 | 
			
		||||
 | 
			
		||||
	 <varlistentry>
 | 
			
		||||
	  <term><literal>RTREE</></term>
 | 
			
		||||
	  <listitem>
 | 
			
		||||
	   <para>implements standard R-trees using Guttman's
 | 
			
		||||
	    quadratic split algorithm.
 | 
			
		||||
	   </para>
 | 
			
		||||
	  </listitem>
 | 
			
		||||
	 </varlistentry>
 | 
			
		||||
 | 
			
		||||
	 <varlistentry>
 | 
			
		||||
	  <term><literal>HASH</></term>
 | 
			
		||||
	  <listitem>
 | 
			
		||||
	   <para>
 | 
			
		||||
	    an implementation of Litwin's linear hashing.
 | 
			
		||||
	   </para>
 | 
			
		||||
	  </listitem>
 | 
			
		||||
	 </varlistentry>
 | 
			
		||||
 | 
			
		||||
	 <varlistentry>
 | 
			
		||||
	  <term><literal>GIST</></term>
 | 
			
		||||
	  <listitem>
 | 
			
		||||
	   <para>
 | 
			
		||||
	    Generalized Index Search Trees.
 | 
			
		||||
	   </para>
 | 
			
		||||
	  </listitem>
 | 
			
		||||
	 </varlistentry>
 | 
			
		||||
	</variablelist>
 | 
			
		||||
        The name of the method to be used for the index.  Choices are
 | 
			
		||||
        <literal>btree</literal>, <literal>hash</literal>,
 | 
			
		||||
        <literal>rtree</literal>, and <literal>gist</literal>.  The
 | 
			
		||||
        default method is <literal>btree</literal>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -159,249 +182,73 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEINDEX-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-09</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE INDEX
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The message returned if the index is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE INDEX</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the index was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR: Cannot create index: 'index_name' already exists.
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	This error occurs if it is impossible to create the index.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEINDEX-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>1998-09-09</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE INDEX</command> constructs an index 
 | 
			
		||||
   <replaceable class="parameter">index_name</replaceable>
 | 
			
		||||
   on the specified <replaceable class="parameter">table</replaceable>.
 | 
			
		||||
 | 
			
		||||
   <tip>
 | 
			
		||||
    <para>
 | 
			
		||||
     Indexes are primarily used to enhance database performance.
 | 
			
		||||
     But inappropriate use will result in slower performance.
 | 
			
		||||
    </para>
 | 
			
		||||
   </tip>
 | 
			
		||||
   See <xref linkend="indexes"> for information about when indexes can
 | 
			
		||||
   be used, when they are not used, and in which particular situations
 | 
			
		||||
   can be useful.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   In the first syntax shown above, the key field(s) for the
 | 
			
		||||
   index are specified as column names.
 | 
			
		||||
   Multiple fields can be specified if the index access method supports
 | 
			
		||||
   multicolumn indexes.
 | 
			
		||||
   Currently, only the B-tree and GiST index methods support
 | 
			
		||||
   multicolumn indexes. Up to 32 fields may be specified by default.
 | 
			
		||||
   (This limit can be altered when building
 | 
			
		||||
   <application>PostgreSQL</application>.)  Only B-tree currently
 | 
			
		||||
   supports unique indexes.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   In the second syntax shown above, an index is defined on the result
 | 
			
		||||
   of a user-specified function <replaceable
 | 
			
		||||
   class="parameter">func_name</replaceable> applied to one or more
 | 
			
		||||
   columns of a single table. These <firstterm>functional
 | 
			
		||||
   indexes</firstterm> can be used to obtain fast access to data based
 | 
			
		||||
   on operators that would normally require some transformation to apply
 | 
			
		||||
   them to the base data. For example, a functional index on
 | 
			
		||||
   <literal>upper(col)</> would allow the clause
 | 
			
		||||
   <literal>WHERE upper(col) = 'JIM'</> to use an index.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <application>PostgreSQL</application> provides B-tree, R-tree, hash,
 | 
			
		||||
   and GiST access methods for indexes. The B-tree access method is an
 | 
			
		||||
   implementation of Lehman-Yao high-concurrency B-trees. The R-tree
 | 
			
		||||
   access method implements standard R-trees using Guttman's quadratic
 | 
			
		||||
   split algorithm. The hash access method is an implementation of
 | 
			
		||||
   Litwin's linear hashing. We mention the algorithms used solely to
 | 
			
		||||
   indicate that all of these access methods are fully dynamic and do
 | 
			
		||||
   not have to be optimized periodically (as is the case with, for
 | 
			
		||||
   example, static hash access methods).
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
    When the <command>WHERE</command> clause is present, a
 | 
			
		||||
    <firstterm>partial index</firstterm> is created.
 | 
			
		||||
    A partial index is an index that contains entries for only a portion of
 | 
			
		||||
    a table, usually a portion that is somehow more interesting than the
 | 
			
		||||
    rest of the table. For example, if you have a table that contains both
 | 
			
		||||
    billed and unbilled orders where the unbilled orders take up a small
 | 
			
		||||
    fraction of the total table and yet that is an often used section, you
 | 
			
		||||
    can improve performance by creating an index on just that portion.
 | 
			
		||||
    Another possible application is to use <command>WHERE</command> with
 | 
			
		||||
    <command>UNIQUE</command> to enforce uniqueness over a subset of a
 | 
			
		||||
    table.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
    The expression used in the <command>WHERE</command> clause may refer
 | 
			
		||||
    only to columns of the underlying table (but it can use all columns,
 | 
			
		||||
    not only the one(s) being indexed).  Presently, subqueries and
 | 
			
		||||
    aggregate expressions are also forbidden in <command>WHERE</command>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   All functions and operators used in an index definition must be
 | 
			
		||||
   <firstterm>immutable</>, that is, their results must depend only on
 | 
			
		||||
   their input arguments and never on any outside influence (such as
 | 
			
		||||
   the contents of another table or the current time).  This restriction
 | 
			
		||||
   ensures that the behavior of the index is well-defined.  To use a
 | 
			
		||||
   user-defined function in an index, remember to mark the function immutable
 | 
			
		||||
   when you create it.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <xref linkend="sql-dropindex" endterm="sql-dropindex-title">
 | 
			
		||||
   to remove an index.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEINDEX-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-09</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The <productname>PostgreSQL</productname>
 | 
			
		||||
    query optimizer will consider using a B-tree index whenever
 | 
			
		||||
    an indexed attribute is involved in a comparison using one of:
 | 
			
		||||
 | 
			
		||||
    <simplelist type="inline">
 | 
			
		||||
     <member><</member>
 | 
			
		||||
     <member><=</member>
 | 
			
		||||
     <member>=</member>
 | 
			
		||||
     <member>>=</member>
 | 
			
		||||
     <member>></member>
 | 
			
		||||
    </simplelist>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The <productname>PostgreSQL</productname>
 | 
			
		||||
    query optimizer will consider using an R-tree index whenever
 | 
			
		||||
    an indexed attribute is involved in a comparison using one of:
 | 
			
		||||
 | 
			
		||||
    <simplelist type="inline">
 | 
			
		||||
     <member><<</member>
 | 
			
		||||
     <member>&<</member>
 | 
			
		||||
     <member>&></member>
 | 
			
		||||
     <member>>></member>
 | 
			
		||||
     <member>@</member>
 | 
			
		||||
     <member>~=</member>
 | 
			
		||||
     <member>&&</member>
 | 
			
		||||
    </simplelist>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The <productname>PostgreSQL</productname>
 | 
			
		||||
    query optimizer will consider using a hash index whenever
 | 
			
		||||
    an indexed attribute is involved in a comparison using
 | 
			
		||||
    the <literal>=</literal> operator.
 | 
			
		||||
   </para>
 | 
			
		||||
   <para>
 | 
			
		||||
     Testing has shown PostgreSQL's hash indexes to be similar or slower
 | 
			
		||||
     than B-tree indexes, and the index size and build time for hash
 | 
			
		||||
     indexes is much worse. Hash indexes also suffer poor performance
 | 
			
		||||
     under high concurrency. For these reasons, hash index use is
 | 
			
		||||
     discouraged.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Currently, only the B-tree and gist access methods support multicolumn
 | 
			
		||||
    indexes. Up to 32 keys may be specified by default (this limit
 | 
			
		||||
    can be altered when building
 | 
			
		||||
    <application>PostgreSQL</application>).  Only B-tree currently supports
 | 
			
		||||
    unique indexes.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   An <firstterm>operator class</firstterm> can be specified for each
 | 
			
		||||
   column of an index. The operator class identifies the operators to be
 | 
			
		||||
   used by the index for that column. For example, a B-tree index on
 | 
			
		||||
   four-byte integers would use the <literal>int4_ops</literal> class;
 | 
			
		||||
   this operator class includes comparison functions for four-byte
 | 
			
		||||
   integers. In practice the default operator class for the field's data
 | 
			
		||||
   integers. In practice the default operator class for the column's data
 | 
			
		||||
   type is usually sufficient. The main point of having operator classes
 | 
			
		||||
   is that for some data types, there could be more than one meaningful
 | 
			
		||||
   ordering. For example, we might want to sort a complex-number data
 | 
			
		||||
   type either by absolute value or by real part. We could do this by
 | 
			
		||||
   defining two operator classes for the data type and then selecting
 | 
			
		||||
   the proper class when making an index. There are also some operator
 | 
			
		||||
   classes with special purposes:
 | 
			
		||||
 | 
			
		||||
   <itemizedlist>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The operator classes <literal>box_ops</literal> and
 | 
			
		||||
      <literal>bigbox_ops</literal> both support R-tree indexes on the
 | 
			
		||||
      <literal>box</literal> data type.
 | 
			
		||||
      The difference between them is that <literal>bigbox_ops</literal>
 | 
			
		||||
      scales box coordinates down, to avoid floating-point exceptions from
 | 
			
		||||
      doing multiplication, addition, and subtraction on very large
 | 
			
		||||
      floating-point coordinates.  (Note: this was true some time ago,
 | 
			
		||||
      but currently the two operator classes both use floating point
 | 
			
		||||
      and are effectively identical.)
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </itemizedlist>
 | 
			
		||||
   the proper class when making an index.  More information about
 | 
			
		||||
   operator classes is in <xref linkend="indexes-opclass"> and in <xref
 | 
			
		||||
   linkend="xindex">.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The following query shows all defined operator classes:
 | 
			
		||||
 | 
			
		||||
    <programlisting>
 | 
			
		||||
SELECT am.amname AS acc_method,
 | 
			
		||||
       opc.opcname AS ops_name
 | 
			
		||||
    FROM pg_am am, pg_opclass opc
 | 
			
		||||
    WHERE opc.opcamid = am.oid
 | 
			
		||||
    ORDER BY acc_method, ops_name;
 | 
			
		||||
    </programlisting>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <xref linkend="sql-dropindex" endterm="sql-dropindex-title">
 | 
			
		||||
   to remove an index.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEINDEX-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>To create a B-tree index on the field <literal>title</literal>
 | 
			
		||||
   in the table <literal>films</literal>:
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To create a B-tree index on the column <literal>title</literal> in
 | 
			
		||||
   the table <literal>films</literal>:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE UNIQUE INDEX title_idx ON films (title);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
  <programlisting>
 | 
			
		||||
CREATE UNIQUE INDEX title_idx
 | 
			
		||||
    ON films (title);
 | 
			
		||||
  </programlisting>
 | 
			
		||||
 | 
			
		||||
<!--
 | 
			
		||||
<comment>
 | 
			
		||||
@ -422,25 +269,14 @@ SELECT * FROM points
 | 
			
		||||
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEINDEX-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEINDEX-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-09</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    CREATE INDEX is a <productname>PostgreSQL</productname> language extension.
 | 
			
		||||
   </para>
 | 
			
		||||
   <para>
 | 
			
		||||
    There is no <command>CREATE INDEX</command> command in SQL92.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE INDEX</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> language extension.  There
 | 
			
		||||
   are no provisions for indexes in the SQL standard.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_language.sgml,v 1.31 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_language.sgml,v 1.32 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -60,7 +60,7 @@ CREATE [ TRUSTED ] [ PROCEDURAL ] LANGUAGE <replaceable class="parameter">langna
 | 
			
		||||
       <literal>TRUSTED</literal> specifies that the call handler for
 | 
			
		||||
       the language is safe, that is, it does not offer an
 | 
			
		||||
       unprivileged user any functionality to bypass access
 | 
			
		||||
       restrictions. If this keyword is omitted when registering the
 | 
			
		||||
       restrictions. If this key word is omitted when registering the
 | 
			
		||||
       language, only users with the
 | 
			
		||||
       <productname>PostgreSQL</productname> superuser privilege can
 | 
			
		||||
       use this language to create new functions.
 | 
			
		||||
@ -84,8 +84,8 @@ CREATE [ TRUSTED ] [ PROCEDURAL ] LANGUAGE <replaceable class="parameter">langna
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       The name of the new procedural language.  The language name is
 | 
			
		||||
       case insensitive. A procedural language cannot override one of
 | 
			
		||||
       the built-in languages of <productname>PostgreSQL</productname>.
 | 
			
		||||
       case insensitive. The name must be unique among the languages
 | 
			
		||||
       in the database.
 | 
			
		||||
      </para>
 | 
			
		||||
 | 
			
		||||
      <para>
 | 
			
		||||
@ -146,45 +146,16 @@ CREATE [ TRUSTED ] [ PROCEDURAL ] LANGUAGE <replaceable class="parameter">langna
 | 
			
		||||
 <refsect1 id="sql-createlanguage-diagnostics">
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <msgset>
 | 
			
		||||
   <msgentry>
 | 
			
		||||
    <msg>
 | 
			
		||||
     <msgmain>
 | 
			
		||||
      <msgtext>
 | 
			
		||||
<screen>
 | 
			
		||||
CREATE LANGUAGE
 | 
			
		||||
</screen>
 | 
			
		||||
      </msgtext>
 | 
			
		||||
     </msgmain>
 | 
			
		||||
    </msg>
 | 
			
		||||
 
 | 
			
		||||
    <msgexplan>
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE LANGUAGE</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      This message is returned if the language is successfully
 | 
			
		||||
      created.
 | 
			
		||||
      Message returned if the language was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </msgexplan>
 | 
			
		||||
   </msgentry>
 | 
			
		||||
 | 
			
		||||
   <msgentry>
 | 
			
		||||
    <msg>
 | 
			
		||||
     <msgmain>
 | 
			
		||||
      <msgtext>
 | 
			
		||||
<screen>
 | 
			
		||||
ERROR:  PL handler function <replaceable class="parameter">funcname</replaceable>() doesn't exist
 | 
			
		||||
</screen>
 | 
			
		||||
      </msgtext>
 | 
			
		||||
     </msgmain>
 | 
			
		||||
    </msg>
 | 
			
		||||
 | 
			
		||||
    <msgexplan>
 | 
			
		||||
     <para>
 | 
			
		||||
      This error is returned if the function <replaceable
 | 
			
		||||
      class="parameter">funcname</replaceable>() is not found.
 | 
			
		||||
     </para>
 | 
			
		||||
    </msgexplan>
 | 
			
		||||
   </msgentry>
 | 
			
		||||
  </msgset>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="sql-createlanguage-notes">
 | 
			
		||||
@ -194,7 +165,7 @@ ERROR:  PL handler function <replaceable class="parameter">funcname</replaceable
 | 
			
		||||
   This command normally should not be executed directly by users.
 | 
			
		||||
   For the procedural languages supplied in the
 | 
			
		||||
   <productname>PostgreSQL</productname> distribution, the <xref
 | 
			
		||||
   linkend="app-createlang"> script should be used, which will also
 | 
			
		||||
   linkend="app-createlang"> program should be used, which will also
 | 
			
		||||
   install the correct call handler.  (<command>createlang</command>
 | 
			
		||||
   will call <command>CREATE LANGUAGE</command> internally.)
 | 
			
		||||
  </para>
 | 
			
		||||
@ -205,7 +176,7 @@ ERROR:  PL handler function <replaceable class="parameter">funcname</replaceable
 | 
			
		||||
   type <type>opaque</>, rather than <type>language_handler</>.
 | 
			
		||||
   To support loading 
 | 
			
		||||
   of old dump files, <command>CREATE LANGUAGE</> will accept a function
 | 
			
		||||
   declared as returning <type>opaque</>, but it will issue a NOTICE and
 | 
			
		||||
   declared as returning <type>opaque</>, but it will issue a notice and
 | 
			
		||||
   change the function's declared return type to <type>language_handler</>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
@ -216,35 +187,19 @@ ERROR:  PL handler function <replaceable class="parameter">funcname</replaceable
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <xref linkend="sql-droplanguage" endterm="sql-droplanguage-title">, or better yet the <xref
 | 
			
		||||
   linkend="app-droplang"> script, to drop procedural languages.
 | 
			
		||||
   linkend="app-droplang"> program, to drop procedural languages.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The system catalog <classname>pg_language</classname> records
 | 
			
		||||
   information about the currently installed procedural languages.
 | 
			
		||||
 | 
			
		||||
<screen>
 | 
			
		||||
        Table "pg_language"
 | 
			
		||||
   Attribute   |   Type    | Modifier
 | 
			
		||||
---------------+-----------+----------
 | 
			
		||||
 lanname       | name      |
 | 
			
		||||
 lanispl       | boolean   |
 | 
			
		||||
 lanpltrusted  | boolean   |
 | 
			
		||||
 lanplcallfoid | oid       |
 | 
			
		||||
 lanvalidator  | oid       |
 | 
			
		||||
 lanacl        | aclitem[] |
 | 
			
		||||
 | 
			
		||||
   lanname   | lanispl | lanpltrusted | lanplcallfoid | lanvalidator | lanacl
 | 
			
		||||
-------------+---------+--------------+---------------+--------------+--------
 | 
			
		||||
 internal    | f       | f            |             0 |         2246 |
 | 
			
		||||
 c           | f       | f            |             0 |         2247 |
 | 
			
		||||
 sql         | f       | t            |             0 |         2248 | {=U}
 | 
			
		||||
</screen>
 | 
			
		||||
   The system catalog <classname>pg_language</classname> (see <xref
 | 
			
		||||
   linkend="catalog-pg-language">) records information about the
 | 
			
		||||
   currently installed languages.  Also <command>createlang</command>
 | 
			
		||||
   has an option to list the installed languages.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   At present, with the exception of the permissions, the definition 
 | 
			
		||||
   of a procedural language cannot be changed once it has been created.
 | 
			
		||||
   The definition of a procedural language cannot be changed once it
 | 
			
		||||
   has been created, with the exception of the privileges.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
@ -262,7 +217,7 @@ ERROR:  PL handler function <replaceable class="parameter">funcname</replaceable
 | 
			
		||||
   The following two commands executed in sequence will register a new
 | 
			
		||||
   procedural language and the associated call handler.
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE FUNCTION plsample_call_handler () RETURNS language_handler
 | 
			
		||||
CREATE FUNCTION plsample_call_handler() RETURNS language_handler
 | 
			
		||||
    AS '$libdir/plsample'
 | 
			
		||||
    LANGUAGE C;
 | 
			
		||||
CREATE LANGUAGE plsample
 | 
			
		||||
@ -280,15 +235,6 @@ CREATE LANGUAGE plsample
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>History</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <command>CREATE LANGUAGE</command> command first appeared in
 | 
			
		||||
   <productname>PostgreSQL</productname> 6.3.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>See Also</title>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_opclass.sgml,v 1.6 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_opclass.sgml,v 1.7 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,206 +8,44 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createopclass-title">CREATE OPERATOR CLASS</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE OPERATOR CLASS
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new operator class for indexes
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  </refnamediv>
 | 
			
		||||
  <refname>CREATE OPERATOR CLASS</refname>
 | 
			
		||||
  <refpurpose>define a new operator class for indexes</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2002-07-28</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAULT ] FOR TYPE <replaceable class="parameter">data_type</replaceable> USING <replaceable class="parameter">access_method</replaceable> AS
 | 
			
		||||
  {  OPERATOR <replaceable class="parameter">strategy_number</replaceable> <replaceable class="parameter">operator_id</replaceable> [ ( <replaceable class="parameter">type</replaceable>, <replaceable class="parameter">type</replaceable> ) ] [ RECHECK ]
 | 
			
		||||
   | FUNCTION <replaceable class="parameter">support_number</replaceable> <replaceable class="parameter">func_name</replaceable> ( <replaceable class="parameter">parameter_types</replaceable> )
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAULT ] FOR TYPE <replaceable class="parameter">data_type</replaceable> USING <replaceable class="parameter">index_method</replaceable> AS
 | 
			
		||||
  {  OPERATOR <replaceable class="parameter">strategy_number</replaceable> <replaceable class="parameter">operator_name</replaceable> [ ( <replaceable class="parameter">op_type</replaceable>, <replaceable class="parameter">op_type</replaceable> ) ] [ RECHECK ]
 | 
			
		||||
   | FUNCTION <replaceable class="parameter">support_number</replaceable> <replaceable class="parameter">func_name</replaceable> ( <replaceable class="parameter">argument_types</replaceable> )
 | 
			
		||||
   | STORAGE <replaceable class="parameter">storage_type</replaceable>
 | 
			
		||||
  } [, ... ]
 | 
			
		||||
  </synopsis>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPCLASS-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2002-07-28</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of the operator class to be created.
 | 
			
		||||
	The name may be schema-qualified.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><literal>DEFAULT</></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        If present, the operator class will become the default index
 | 
			
		||||
	operator class for its data type.  At most one operator class
 | 
			
		||||
	can be the default for a specific data type and access method.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">data_type</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The column data type that this operator class is for.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">access_method</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of the index access method this operator class is for.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">strategy_number</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The index access method's strategy number for an operator associated
 | 
			
		||||
	with the operator class.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">operator_id</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The identifier (optionally schema-qualified) of an operator associated
 | 
			
		||||
	with the operator class.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">type</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The input data type(s) of an operator, or <literal>NONE</> to
 | 
			
		||||
	signify a left-unary or right-unary operator.  The input data types
 | 
			
		||||
	may be omitted in the normal case where they are the same as the
 | 
			
		||||
	operator class's data type.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><literal>RECHECK</></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        If present, the index is <quote>lossy</> for this operator,
 | 
			
		||||
	and so the tuples retrieved using the index must be rechecked
 | 
			
		||||
	to verify that they actually satisfy the qualification clause
 | 
			
		||||
	involving this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">support_number</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The index access method's support procedure number for a function
 | 
			
		||||
	associated with the operator class.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">func_name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The name (optionally schema-qualified) of a function that is
 | 
			
		||||
	an index access method support procedure for the operator class.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">parameter_types</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The parameter data type(s) of the function.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">storage_type</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The data type actually stored in the index.  Normally this is the
 | 
			
		||||
	same as the column data type, but some index access methods (only
 | 
			
		||||
	GIST at this writing) allow it to be different.  The
 | 
			
		||||
	<literal>STORAGE</> clause must be omitted unless the index access
 | 
			
		||||
	method allows a different type to be used.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPCLASS-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2002-07-28</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE OPERATOR CLASS
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the operator class is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEOPCLASS-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2002-07-28</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OPERATOR CLASS</command> defines a new operator class,
 | 
			
		||||
   <replaceable class="parameter">name</replaceable>.
 | 
			
		||||
  </para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OPERATOR CLASS</command> creates a new operator class.
 | 
			
		||||
   An operator class defines how a particular data type can be used with
 | 
			
		||||
   an index.  The operator class specifies that certain operators will fill
 | 
			
		||||
   particular roles or <quote>strategies</> for this data type and this
 | 
			
		||||
   access method.  The operator class also specifies the support procedures to
 | 
			
		||||
   index method.  The operator class also specifies the support procedures to
 | 
			
		||||
   be used by 
 | 
			
		||||
   the index access method when the operator class is selected for an
 | 
			
		||||
   the index method when the operator class is selected for an
 | 
			
		||||
   index column.  All the operators and functions used by an operator
 | 
			
		||||
   class must be defined before the operator class is created.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given then the operator class is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
   Two operator classes in the same schema can have the same name only if they
 | 
			
		||||
   are for different index access methods.
 | 
			
		||||
   are for different index methods.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The user who defines an operator class becomes its owner.  Presently,
 | 
			
		||||
   the creating user must be a superuser.  (This restriction is made because
 | 
			
		||||
@ -217,41 +55,187 @@ CREATE OPERATOR CLASS
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OPERATOR CLASS</command> does not presently check
 | 
			
		||||
   whether the class definition includes all the operators and functions
 | 
			
		||||
   required by the index access method.  It is the user's
 | 
			
		||||
   whether the operator class definition includes all the operators and functions
 | 
			
		||||
   required by the index method.  It is the user's
 | 
			
		||||
   responsibility to define a valid operator class.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Refer to <xref linkend="xindex"> for further information.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPCLASS-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2002-07-28</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    Refer to
 | 
			
		||||
    <xref linkend="sql-dropopclass" endterm="sql-dropopclass-title">
 | 
			
		||||
    to delete user-defined operator classes from a database.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEOPCLASS-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of the operator class to be created.  The name may be
 | 
			
		||||
      schema-qualified.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>DEFAULT</></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      If present, the operator class will become the default
 | 
			
		||||
      operator class for its data type.  At most one operator class
 | 
			
		||||
      can be the default for a specific data type and index method.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">data_type</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The column data type that this operator class is for.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">index_method</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of the index method this operator class is for.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">strategy_number</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The index method's strategy number for an operator
 | 
			
		||||
      associated with the operator class.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">operator_name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of an operator associated
 | 
			
		||||
      with the operator class.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">op_type</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The operand data type(s) of an operator, or <literal>NONE</> to
 | 
			
		||||
      signify a left-unary or right-unary operator.  The operand data
 | 
			
		||||
      types may be omitted in the normal case where they are the same
 | 
			
		||||
      as the operator class's data type.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>RECHECK</></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      If present, the index is <quote>lossy</> for this operator, and
 | 
			
		||||
      so the rows retrieved using the index must be rechecked to
 | 
			
		||||
      verify that they actually satisfy the qualification clause
 | 
			
		||||
      involving this operator.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">support_number</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The index method's support procedure number for a
 | 
			
		||||
      function associated with the operator class.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">func_name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of a function that is an
 | 
			
		||||
      index method support procedure for the operator class.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">argument_types</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The parameter data type(s) of the function.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">storage_type</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The data type actually stored in the index.  Normally this is
 | 
			
		||||
      the same as the column data type, but some index methods
 | 
			
		||||
      (only GiST at this writing) allow it to be different.  The
 | 
			
		||||
      <literal>STORAGE</> clause must be omitted unless the index
 | 
			
		||||
      method allows a different type to be used.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <literal>OPERATOR</>, <literal>FUNCTION</>, and <literal>STORAGE</>
 | 
			
		||||
   clauses may appear in any order.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE OPERATOR CLASS</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the operator class was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Refer to
 | 
			
		||||
   <xref linkend="sql-dropopclass" endterm="sql-dropopclass-title">
 | 
			
		||||
   to delete user-defined operator classes from a database.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The following example command defines a GiST index operator class
 | 
			
		||||
   for data type <literal>_int4</> (array of int4).  See
 | 
			
		||||
   for the data type <literal>_int4</> (array of <type>int4</type>).  See
 | 
			
		||||
   <filename>contrib/intarray/</> for the complete example.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE OPERATOR CLASS gist__int_ops
 | 
			
		||||
    DEFAULT FOR TYPE _int4 USING gist AS
 | 
			
		||||
        OPERATOR        3       &&,
 | 
			
		||||
@ -266,34 +250,18 @@ CREATE OPERATOR CLASS gist__int_ops
 | 
			
		||||
        FUNCTION        5       g_int_penalty (internal, internal, internal),
 | 
			
		||||
        FUNCTION        6       g_int_picksplit (internal, internal),
 | 
			
		||||
        FUNCTION        7       g_int_same (_int4, _int4, internal);
 | 
			
		||||
  </programlisting>  
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <literal>OPERATOR</>, <literal>FUNCTION</>, and <literal>STORAGE</>
 | 
			
		||||
   clauses may appear in any order.
 | 
			
		||||
  </para>
 | 
			
		||||
</programlisting>  
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEOPCLASS-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPCLASS-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2002-07-28</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE OPERATOR CLASS</command>
 | 
			
		||||
    is a <productname>PostgreSQL</productname> extension.
 | 
			
		||||
    There is no <command>CREATE OPERATOR CLASS</command>
 | 
			
		||||
    statement in <acronym>SQL92</acronym>.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OPERATOR CLASS</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> extension.  There is no
 | 
			
		||||
   <command>CREATE OPERATOR CLASS</command> statement in the SQL
 | 
			
		||||
   standard.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.34 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.35 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,218 +8,43 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createoperator-title">CREATE OPERATOR</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE OPERATOR
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new operator
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  </refnamediv>
 | 
			
		||||
  <refname>CREATE OPERATOR</refname>
 | 
			
		||||
  <refpurpose>define a new operator</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2000-03-25</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
CREATE OPERATOR <replaceable>name</replaceable> ( PROCEDURE = <replaceable class="parameter">func_name</replaceable>
 | 
			
		||||
     [, LEFTARG = <replaceable class="parameter">lefttype</replaceable>
 | 
			
		||||
     ] [, RIGHTARG = <replaceable class="parameter">righttype</replaceable> ]
 | 
			
		||||
     [, COMMUTATOR = <replaceable class="parameter">com_op</replaceable> ] [, NEGATOR = <replaceable class="parameter">neg_op</replaceable> ]
 | 
			
		||||
     [, RESTRICT = <replaceable class="parameter">res_proc</replaceable> ] [, JOIN = <replaceable class="parameter">join_proc</replaceable> ]
 | 
			
		||||
     [, HASHES ] [, MERGES ]
 | 
			
		||||
     [, SORT1 = <replaceable class="parameter">left_sort_op</replaceable> ] [, SORT2 = <replaceable class="parameter">right_sort_op</replaceable> ]
 | 
			
		||||
     [, LTCMP = <replaceable class="parameter">less_than_op</replaceable> ] [, GTCMP = <replaceable class="parameter">greater_than_op</replaceable> ] )
 | 
			
		||||
  </synopsis>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPERATOR-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The operator to be defined. See below for allowable characters.
 | 
			
		||||
	The name may be schema-qualified, for example
 | 
			
		||||
	<literal>CREATE OPERATOR myschema.+ (...)</>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">func_name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The function used to implement this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">lefttype</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The type of the left-hand argument of the operator, if any.
 | 
			
		||||
	This option would be omitted for a left-unary operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">righttype</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The type of the right-hand argument of the operator, if any.
 | 
			
		||||
	This option would be omitted for a right-unary operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">com_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The commutator of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">neg_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The negator of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">res_proc</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The restriction selectivity estimator function for this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">join_proc</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The join selectivity estimator function for this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>HASHES</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
       Indicates this operator can support a hash join.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>MERGES</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
       Indicates this operator can support a merge join.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">left_sort_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the less-than
 | 
			
		||||
	operator that sorts the left-hand data type of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">right_sort_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the less-than
 | 
			
		||||
	operator that sorts the right-hand data type of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">less_than_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the less-than
 | 
			
		||||
	operator that compares the input data types of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">greater_than_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the greater-than
 | 
			
		||||
	operator that compares the input data types of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPERATOR-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE OPERATOR
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the operator is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE OPERATOR <replaceable>name</replaceable> (
 | 
			
		||||
    PROCEDURE = <replaceable class="parameter">func_name</replaceable>
 | 
			
		||||
    [, LEFTARG = <replaceable class="parameter">lefttype</replaceable> ] [, RIGHTARG = <replaceable class="parameter">righttype</replaceable> ]
 | 
			
		||||
    [, COMMUTATOR = <replaceable class="parameter">com_op</replaceable> ] [, NEGATOR = <replaceable class="parameter">neg_op</replaceable> ]
 | 
			
		||||
    [, RESTRICT = <replaceable class="parameter">res_proc</replaceable> ] [, JOIN = <replaceable class="parameter">join_proc</replaceable> ]
 | 
			
		||||
    [, HASHES ] [, MERGES ]
 | 
			
		||||
    [, SORT1 = <replaceable class="parameter">left_sort_op</replaceable> ] [, SORT2 = <replaceable class="parameter">right_sort_op</replaceable> ]
 | 
			
		||||
    [, LTCMP = <replaceable class="parameter">less_than_op</replaceable> ] [, GTCMP = <replaceable class="parameter">greater_than_op</replaceable> ]
 | 
			
		||||
)
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEOPERATOR-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2000-03-25</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OPERATOR</command>  defines a new operator,
 | 
			
		||||
   <replaceable class="parameter">name</replaceable>.
 | 
			
		||||
   The user who defines an operator becomes its owner.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given then the operator is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Two operators in the same schema can have the same name if they operate on
 | 
			
		||||
   different data types.  This is called <firstterm>overloading</>.  The
 | 
			
		||||
   system will attempt to pick the intended operator based on the actual
 | 
			
		||||
   input data types when there is ambiguity.
 | 
			
		||||
   <command>CREATE OPERATOR</command> defines a new operator,
 | 
			
		||||
   <replaceable class="parameter">name</replaceable>.  The user who
 | 
			
		||||
   defines an operator becomes its owner.  If a schema name is given
 | 
			
		||||
   then the operator is created in the specified schema.  Otherwise it
 | 
			
		||||
   is created in the current schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The operator <replaceable class="parameter">name</replaceable>
 | 
			
		||||
   is a sequence of up to <symbol>NAMEDATALEN</>-1 (63 by default) characters
 | 
			
		||||
   from the following list:
 | 
			
		||||
   <literallayout>
 | 
			
		||||
   The operator name is a sequence of up to <symbol>NAMEDATALEN</>-1
 | 
			
		||||
   (63 by default) characters from the following list:
 | 
			
		||||
<literallayout>
 | 
			
		||||
+ - * / < > = ~ ! @ # % ^ & | ` ? $
 | 
			
		||||
   </literallayout>
 | 
			
		||||
</literallayout>
 | 
			
		||||
 | 
			
		||||
   There are a few restrictions on your choice of name:
 | 
			
		||||
   <itemizedlist>
 | 
			
		||||
@ -240,263 +65,258 @@ CREATE OPERATOR
 | 
			
		||||
     A multicharacter operator name cannot end in <literal>+</literal> or
 | 
			
		||||
     <literal>-</literal>,
 | 
			
		||||
     unless the name also contains at least one of these characters:
 | 
			
		||||
     <literallayout>
 | 
			
		||||
<literallayout>
 | 
			
		||||
~ ! @ # % ^ & | ` ? $
 | 
			
		||||
     </literallayout>
 | 
			
		||||
</literallayout>
 | 
			
		||||
     For example, <literal>@-</literal> is an allowed operator name,
 | 
			
		||||
     but <literal>*-</literal> is not.
 | 
			
		||||
     This restriction allows <productname>PostgreSQL</productname> to
 | 
			
		||||
     parse SQL-compliant queries without requiring spaces between tokens.
 | 
			
		||||
     parse SQL-compliant commands without requiring spaces between tokens.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </itemizedlist>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <note>
 | 
			
		||||
    <para>
 | 
			
		||||
     When working with non-SQL-standard operator names, you will usually
 | 
			
		||||
     need to separate adjacent operators with spaces to avoid ambiguity.
 | 
			
		||||
     For example, if you have defined a left-unary operator named <literal>@</literal>,
 | 
			
		||||
     you cannot write <literal>X*@Y</literal>; you must write
 | 
			
		||||
     <literal>X* @Y</literal> to ensure that
 | 
			
		||||
     <productname>PostgreSQL</productname> reads it as two operator names
 | 
			
		||||
     not one.
 | 
			
		||||
     </para>
 | 
			
		||||
   </note>   
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The operator <literal>!=</literal> is mapped to <literal><></literal> on input, so these two names
 | 
			
		||||
   are always equivalent.
 | 
			
		||||
   The operator <literal>!=</literal> is mapped to
 | 
			
		||||
   <literal><></literal> on input, so these two names are always
 | 
			
		||||
   equivalent.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   At least one of <literal>LEFTARG</> and <literal>RIGHTARG</> must be defined.  For
 | 
			
		||||
   binary operators, both should be defined. For right  unary
 | 
			
		||||
   operators,  only  <literal>LEFTARG</>  should  be defined, while for left
 | 
			
		||||
   binary operators, both must be defined. For right  unary
 | 
			
		||||
   operators, only <literal>LEFTARG</> should be defined, while for left
 | 
			
		||||
   unary operators only <literal>RIGHTARG</> should be defined.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The
 | 
			
		||||
   <replaceable class="parameter">func_name</replaceable> procedure must have
 | 
			
		||||
   been previously defined using <command>CREATE FUNCTION</command> and  must
 | 
			
		||||
   be defined to accept the correct number of arguments
 | 
			
		||||
   (either  one or two) of the indicated types.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The commutator operator should be identified if one exists,
 | 
			
		||||
   so that <productname>PostgreSQL</productname> can
 | 
			
		||||
   reverse the order of the operands if it wishes.
 | 
			
		||||
   For example, the operator area-less-than, <<<,
 | 
			
		||||
   would probably have a commutator
 | 
			
		||||
   operator, area-greater-than, >>>.
 | 
			
		||||
   Hence, the query optimizer could freely  convert:
 | 
			
		||||
 | 
			
		||||
   <programlisting>
 | 
			
		||||
box '((0,0), (1,1))'  >>> MYBOXES.description
 | 
			
		||||
   </programlisting>
 | 
			
		||||
  <para>
 | 
			
		||||
   The <replaceable class="parameter">func_name</replaceable>
 | 
			
		||||
   procedure must have been previously defined using <command>CREATE
 | 
			
		||||
   FUNCTION</command> and must be defined to accept the correct number
 | 
			
		||||
   of arguments (either one or two) of the indicated types.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   to
 | 
			
		||||
  <para>
 | 
			
		||||
   The other clauses specify optional operator optimization clauses.
 | 
			
		||||
   Their meaning is detailed in <xref linkend="xoper">.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of the operator to be defined. See above for allowable
 | 
			
		||||
	characters.  The name may be schema-qualified, for example
 | 
			
		||||
	<literal>CREATE OPERATOR myschema.+ (...)</>.  If not, then
 | 
			
		||||
	the operator is created in the current schema.  Two operators
 | 
			
		||||
	in the same schema can have the same name if they operate on
 | 
			
		||||
	different data types.  This is called
 | 
			
		||||
	<firstterm>overloading</>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">func_name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The function used to implement this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">lefttype</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The type of the left-hand argument of the operator, if any.
 | 
			
		||||
	This option would be omitted for a left-unary operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">righttype</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The type of the right-hand argument of the operator, if any.
 | 
			
		||||
	This option would be omitted for a right-unary operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">com_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The commutator of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">neg_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The negator of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">res_proc</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The restriction selectivity estimator function for this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">join_proc</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The join selectivity estimator function for this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><literal>HASHES</literal></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
       Indicates this operator can support a hash join.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><literal>MERGES</literal></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
       Indicates this operator can support a merge join.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">left_sort_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the less-than
 | 
			
		||||
	operator that sorts the left-hand data type of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">right_sort_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the less-than
 | 
			
		||||
	operator that sorts the right-hand data type of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">less_than_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the less-than
 | 
			
		||||
	operator that compares the input data types of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">greater_than_op</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If this operator can support a merge join, the greater-than
 | 
			
		||||
	operator that compares the input data types of this operator.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
 | 
			
		||||
   <programlisting>
 | 
			
		||||
MYBOXES.description <<< box '((0,0), (1,1))'
 | 
			
		||||
   </programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   This  allows  the  execution code to always use the latter
 | 
			
		||||
   representation and simplifies the  query  optimizer  somewhat.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Similarly, if there is a negator operator then it should be
 | 
			
		||||
   identified.
 | 
			
		||||
   Suppose  that  an
 | 
			
		||||
   operator,  area-equal, ===, exists, as well as an area not
 | 
			
		||||
   equal, !==.
 | 
			
		||||
   The negator link allows the query optimizer to simplify
 | 
			
		||||
   <programlisting>
 | 
			
		||||
NOT MYBOXES.description === box '((0,0), (1,1))'
 | 
			
		||||
   </programlisting>
 | 
			
		||||
   to
 | 
			
		||||
   <programlisting>
 | 
			
		||||
MYBOXES.description !== box '((0,0), (1,1))'
 | 
			
		||||
   </programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   If  a  commutator  operator  name  is  supplied,  
 | 
			
		||||
   <productname>PostgreSQL</productname>
 | 
			
		||||
   searches  for  it  in  the catalog.  If it is found and it
 | 
			
		||||
   does not yet have a commutator itself, then the commutator's
 | 
			
		||||
   entry is updated to have the newly created operator as its
 | 
			
		||||
   commutator.  This applies to the negator, as well.
 | 
			
		||||
   This  is to allow the definition of two operators that are
 | 
			
		||||
   the commutators or the negators of each other.  The  first
 | 
			
		||||
   operator should be defined without a commutator or negator
 | 
			
		||||
   (as appropriate).  When the second  operator  is  defined,
 | 
			
		||||
   name  the  first  as the commutator or negator.  The first
 | 
			
		||||
   will be updated as a side effect.  (As of
 | 
			
		||||
   <application>PostgreSQL</application> <literal>6.5</literal>, 
 | 
			
		||||
   it also works to just have both operators refer to each other.)
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The <literal>HASHES</>, <literal>MERGES</>, <literal>SORT1</>,
 | 
			
		||||
   <literal>SORT2</>, <literal>LTCMP</>, and <literal>GTCMP</> options
 | 
			
		||||
   are present to support the query optimizer in performing joins.
 | 
			
		||||
   <productname>PostgreSQL</productname> can always evaluate a join
 | 
			
		||||
   (i.e., processing a clause with two tuple variables separated by an
 | 
			
		||||
   operator that returns a <type>boolean</type>) by iterative
 | 
			
		||||
   substitution <!--[WONG76]-->.  In addition,
 | 
			
		||||
   <productname>PostgreSQL</productname> can use a hash-join algorithm
 | 
			
		||||
   <!--along the lines of [SHAP86]-->; however, it must know whether this
 | 
			
		||||
   strategy is applicable.  The current hash-join algorithm is only
 | 
			
		||||
   correct for operators that represent equality tests; furthermore,
 | 
			
		||||
   equality of the data type must mean bitwise equality of the
 | 
			
		||||
   representation of the type.  (For example, a data type that
 | 
			
		||||
   contains unused bits that don't matter for equality tests could not
 | 
			
		||||
   be hash-joined.)  The <literal>HASHES</> flag indicates to the query optimizer
 | 
			
		||||
   that a hash join may safely be used with this operator.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Similarly, the <literal>MERGES</> flag indicates whether merge-sort
 | 
			
		||||
   is a usable join strategy for this operator.  A merge join requires
 | 
			
		||||
   that the two input data types have consistent orderings, and that
 | 
			
		||||
   the merge-join operator behave like equality with respect to that
 | 
			
		||||
   ordering.  For example, it is possible to merge-join equality
 | 
			
		||||
   between an integer and a float variable by sorting both inputs in
 | 
			
		||||
   ordinary numeric order.  Execution of a merge join requires that
 | 
			
		||||
   the system be able to identify four operators related to the
 | 
			
		||||
   merge-join equality operator: less-than comparison for the left
 | 
			
		||||
   input data type, less-than comparison for the right input data
 | 
			
		||||
   type, less-than comparison between the two data types, and
 | 
			
		||||
   greater-than comparison between the two data types.  It is possible
 | 
			
		||||
   to specify these by name, as the <literal>SORT1</>,
 | 
			
		||||
   <literal>SORT2</>, <literal>LTCMP</>, and <literal>GTCMP</> options
 | 
			
		||||
   respectively.  The system will fill in the default names
 | 
			
		||||
   <literal><</>, <literal><</>, <literal><</>,
 | 
			
		||||
   <literal>></> respectively if any of these are omitted when
 | 
			
		||||
   <literal>MERGES</> is specified.  Also, <literal>MERGES</> will be
 | 
			
		||||
   assumed to be implied if any of these four operator options appear.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   If  other join strategies are found to be practical,
 | 
			
		||||
   <productname>PostgreSQL</productname>
 | 
			
		||||
   will change the optimizer and run-time system to  use
 | 
			
		||||
   them  and  will  require  additional specification when an
 | 
			
		||||
   operator is defined.  Fortunately, the research  community
 | 
			
		||||
   invents  new  join  strategies infrequently, and the added
 | 
			
		||||
   generality of user-defined join strategies was not felt to
 | 
			
		||||
   be worth the complexity involved.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The <literal>RESTRICT</> and <literal>JOIN</> options assist the
 | 
			
		||||
   query optimizer in estimating result sizes.  If a clause of the
 | 
			
		||||
   form:
 | 
			
		||||
   To give a schema-qualified operator name in <replaceable
 | 
			
		||||
   class="parameter">com_op</replaceable> or the other optional
 | 
			
		||||
   arguments, use the <literal>OPERATOR()</> syntax, for example
 | 
			
		||||
<programlisting>
 | 
			
		||||
myboxes.description <<< box '((0,0), (1,1))'
 | 
			
		||||
</programlisting>
 | 
			
		||||
   is present in the qualification,
 | 
			
		||||
   then <productname>PostgreSQL</productname> may have to
 | 
			
		||||
   estimate the fraction of the  instances  in <literal>myboxes</> that
 | 
			
		||||
   satisfy  the clause.  The function
 | 
			
		||||
   <replaceable class="parameter">res_proc</replaceable>
 | 
			
		||||
   must be a registered function (meaning  it  is  already  defined  using
 | 
			
		||||
   <command>CREATE FUNCTION</command>) which accepts arguments of the correct
 | 
			
		||||
   data types and returns a floating-point number.   The
 | 
			
		||||
   query  optimizer  simply  calls this function, passing the
 | 
			
		||||
   parameter <literal>((0,0), (1,1))</literal> and multiplies the result by the relation
 | 
			
		||||
   size to get the expected number of instances.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Similarly, when the operands of the operator both  contain
 | 
			
		||||
   instance  variables, the query optimizer must estimate the
 | 
			
		||||
   size of the resulting join.  The function <function>join_proc</> will
 | 
			
		||||
   return  another floating-point number which will be multiplied
 | 
			
		||||
   by the cardinalities of the two tables involved  to
 | 
			
		||||
   compute the expected result size.
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The difference between the function
 | 
			
		||||
   <programlisting>
 | 
			
		||||
my_procedure_1 (MYBOXES.description, box '((0,0), (1,1))')
 | 
			
		||||
   </programlisting>
 | 
			
		||||
   and the operator
 | 
			
		||||
   <programlisting>
 | 
			
		||||
MYBOXES.description === box '((0,0), (1,1))'
 | 
			
		||||
   </programlisting>
 | 
			
		||||
   is  that  <productname>PostgreSQL</productname>
 | 
			
		||||
   attempts to optimize operators and can
 | 
			
		||||
   decide to use an index to restrict the search  space  when
 | 
			
		||||
   operators  are  involved.  However, there is no attempt to
 | 
			
		||||
   optimize functions, and they are performed by brute force.
 | 
			
		||||
   Moreover, functions can have any number of arguments while
 | 
			
		||||
   operators are restricted to one or two.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPERATOR-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    Refer to <xref linkend="xoper"> for further information.
 | 
			
		||||
    Use <command>DROP OPERATOR</command> to delete
 | 
			
		||||
    user-defined operators from a database.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    To give a schema-qualified operator name in <replaceable
 | 
			
		||||
    class="parameter">com_op</replaceable> or the other optional
 | 
			
		||||
    arguments, use the <literal>OPERATOR()</> syntax, for example
 | 
			
		||||
<programlisting>
 | 
			
		||||
   COMMUTATOR = OPERATOR(myschema.===) ,
 | 
			
		||||
COMMUTATOR = OPERATOR(myschema.===) ,
 | 
			
		||||
</programlisting>  
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE OPERATOR</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the operator was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEOPERATOR-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>The following command defines a new operator,
 | 
			
		||||
   area-equality, for the BOX data type:
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Refer to <xref linkend="xoper"> for further information.
 | 
			
		||||
  </para>
 | 
			
		||||
  <programlisting>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <command>DROP OPERATOR</command> to delete user-defined
 | 
			
		||||
   operators from a database.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The following command defines a new operator, area-equality, for
 | 
			
		||||
   the data type <type>box</type>:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE OPERATOR === (
 | 
			
		||||
   LEFTARG = box,
 | 
			
		||||
   RIGHTARG = box,
 | 
			
		||||
   PROCEDURE = area_equal_procedure,
 | 
			
		||||
   COMMUTATOR = ===,
 | 
			
		||||
   NEGATOR = !==,
 | 
			
		||||
   RESTRICT = area_restriction_procedure,
 | 
			
		||||
   JOIN = area_join_procedure,
 | 
			
		||||
   HASHES,
 | 
			
		||||
   SORT1 = <<<,
 | 
			
		||||
   SORT2 = <<<
 | 
			
		||||
   -- Since sort operators were given, MERGES is implied.
 | 
			
		||||
   -- LTCMP and GTCMP are assumed to be < and > respectively
 | 
			
		||||
    LEFTARG = box,
 | 
			
		||||
    RIGHTARG = box,
 | 
			
		||||
    PROCEDURE = area_equal_procedure,
 | 
			
		||||
    COMMUTATOR = ===,
 | 
			
		||||
    NEGATOR = !==,
 | 
			
		||||
    RESTRICT = area_restriction_procedure,
 | 
			
		||||
    JOIN = area_join_procedure,
 | 
			
		||||
    HASHES,
 | 
			
		||||
    SORT1 = <<<,
 | 
			
		||||
    SORT2 = <<<
 | 
			
		||||
    -- Since sort operators were given, MERGES is implied.
 | 
			
		||||
    -- LTCMP and GTCMP are assumed to be < and > respectively
 | 
			
		||||
);
 | 
			
		||||
  </programlisting>  
 | 
			
		||||
</programlisting>  
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEOPERATOR-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEOPERATOR-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE OPERATOR</command>
 | 
			
		||||
    is a <productname>PostgreSQL</productname> extension.
 | 
			
		||||
    There is no <command>CREATE OPERATOR</command>
 | 
			
		||||
    statement in <acronym>SQL92</acronym>.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OPERATOR</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> extension.  There are no
 | 
			
		||||
   provisions for user-defined operators in the SQL standard.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.38 2002/11/21 23:34:43 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.39 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,138 +8,22 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createrule-title">CREATE RULE</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE RULE
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new rewrite rule
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE RULE</refname>
 | 
			
		||||
  <refpurpose>define a new rewrite rule</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2001-01-05</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS ON <replaceable class="parameter">event</replaceable>
 | 
			
		||||
    TO <replaceable class="parameter">table</replaceable> [ WHERE <replaceable class="parameter">condition</replaceable> ]
 | 
			
		||||
    DO [ INSTEAD ] <replaceable class="parameter">action</replaceable>
 | 
			
		||||
 | 
			
		||||
where <replaceable class="PARAMETER">action</replaceable> can be:
 | 
			
		||||
 | 
			
		||||
NOTHING
 | 
			
		||||
| <replaceable class="parameter">query</replaceable>
 | 
			
		||||
| ( <replaceable class="parameter">query</replaceable> ; <replaceable class="parameter">query</replaceable> ... )
 | 
			
		||||
  </synopsis>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATERULE-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2001-01-05</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of a rule to create.  This must be distinct from the name
 | 
			
		||||
	of any other rule for the same table.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">event</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Event is one of <literal>SELECT</literal>,
 | 
			
		||||
	<literal>UPDATE</literal>, <literal>DELETE</literal>
 | 
			
		||||
	or <literal>INSERT</literal>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">table</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name (optionally schema-qualified) of the table or view the rule
 | 
			
		||||
	applies to.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">condition</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Any SQL conditional expression (returning <type>boolean</type>).
 | 
			
		||||
	The condition expression may not
 | 
			
		||||
	refer to any tables except <literal>new</literal> and
 | 
			
		||||
	<literal>old</literal>, and may not contain aggregate functions.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">query</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The query or queries making up the
 | 
			
		||||
	<replaceable class="PARAMETER">action</replaceable>
 | 
			
		||||
	can be any SQL <literal>SELECT</literal>, <literal>INSERT</literal>,
 | 
			
		||||
	<literal>UPDATE</literal>, <literal>DELETE</literal>, or
 | 
			
		||||
	<literal>NOTIFY</literal> statement.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Within the <replaceable class="parameter">condition</replaceable>
 | 
			
		||||
    and <replaceable class="PARAMETER">action</replaceable>, the special
 | 
			
		||||
    table names <literal>new</literal> and <literal>old</literal> may be
 | 
			
		||||
    used to refer to values in the referenced table.
 | 
			
		||||
    <literal>new</literal> is valid in ON INSERT and ON UPDATE rules
 | 
			
		||||
    to refer to the new row being inserted or updated.
 | 
			
		||||
    <literal>old</literal> is valid in ON UPDATE and ON DELETE
 | 
			
		||||
    rules to refer to the existing row being updated or deleted.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATERULE-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE RULE
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the rule is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
    DO [ INSTEAD ] { NOTHING | <replaceable class="parameter">command</replaceable> | ( <replaceable class="parameter">command</replaceable> ; <replaceable class="parameter">command</replaceable> ... ) }
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATERULE-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>1998-09-11</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE RULE</command> defines a new rule applying to a specified
 | 
			
		||||
@ -150,186 +34,206 @@ CREATE RULE
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <productname>PostgreSQL</productname> 
 | 
			
		||||
   <firstterm>rule system</firstterm> allows one to define an
 | 
			
		||||
   alternate action to be performed on inserts, updates, or deletions
 | 
			
		||||
   from database tables. Rules are used to
 | 
			
		||||
   implement table views as well.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The semantics of a rule is that at the time an individual instance (row)
 | 
			
		||||
   is
 | 
			
		||||
   accessed, inserted, updated, or deleted, there is an old instance (for
 | 
			
		||||
   selects, updates and deletes) and a new instance (for inserts and
 | 
			
		||||
   updates).  All the rules for the given event type and the given target
 | 
			
		||||
   table are examined successively (in order by name).  If the
 | 
			
		||||
   <replaceable class="parameter">condition</replaceable> specified in the
 | 
			
		||||
   WHERE clause (if any) is true, the 
 | 
			
		||||
   <replaceable class="parameter">action</replaceable> part of the rule is
 | 
			
		||||
   executed.  The <replaceable class="parameter">action</replaceable> is
 | 
			
		||||
   done instead of the original query if INSTEAD is specified; otherwise
 | 
			
		||||
   it is done after the original query in the case of ON INSERT, or before
 | 
			
		||||
   the original query in the case of ON UPDATE or ON DELETE.
 | 
			
		||||
   Within both the <replaceable class="parameter">condition</replaceable>
 | 
			
		||||
   and <replaceable class="parameter">action</replaceable>, values from
 | 
			
		||||
   fields in the old instance and/or the new instance are substituted for
 | 
			
		||||
   <literal>old.</literal><replaceable class="parameter">attribute-name</replaceable>
 | 
			
		||||
   and <literal>new.</literal><replaceable class="parameter">attribute-name</replaceable>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <replaceable class="parameter">action</replaceable> part of the
 | 
			
		||||
   rule can consist of one or more queries. To write multiple queries,
 | 
			
		||||
   surround them with parentheses. Such queries will be performed in the
 | 
			
		||||
   specified order. The <replaceable
 | 
			
		||||
   class="parameter">action</replaceable> can also be NOTHING indicating
 | 
			
		||||
   no action. Thus, a DO INSTEAD NOTHING rule suppresses the original
 | 
			
		||||
   query from executing (when its condition is true); a DO NOTHING rule
 | 
			
		||||
   is useless.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <replaceable class="parameter">action</replaceable> part of the rule
 | 
			
		||||
   executes with the same command and transaction identifier as the user
 | 
			
		||||
   command that caused activation.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   It is important to realize that a rule is really a query transformation
 | 
			
		||||
   mechanism, or query macro.  The entire query is processed to convert it
 | 
			
		||||
   into a series of queries that include the rule actions.  This occurs
 | 
			
		||||
   before evaluation of the query starts.  So, conditional rules are
 | 
			
		||||
   handled by adding the rule condition to the WHERE clause of the action(s)
 | 
			
		||||
   derived from the rule.  The above description of a rule as an operation
 | 
			
		||||
   that executes for each row is thus somewhat misleading.  If you actually
 | 
			
		||||
   want an operation that fires independently for each physical row, you
 | 
			
		||||
   probably want to use a trigger not a rule.  Rules are most useful for
 | 
			
		||||
   situations that call for transforming entire queries independently of
 | 
			
		||||
   the specific data being handled.
 | 
			
		||||
   The <productname>PostgreSQL</productname> rule system allows one to
 | 
			
		||||
   define an alternate action to be performed on insertions, updates,
 | 
			
		||||
   or deletions in database tables.  Roughly speaking, a rule causes
 | 
			
		||||
   additional commands to be executed when a given command on a given
 | 
			
		||||
   table is executed.  Alternatively, a rule can replace a given
 | 
			
		||||
   command by another, or cause a command not to be executed at all.
 | 
			
		||||
   Rules are used to implement table views as well.  It is important
 | 
			
		||||
   to realize that a rule is really a command transformation
 | 
			
		||||
   mechanism, or command macro.  The transformation happens before the
 | 
			
		||||
   execution of the commands starts.  If you actually want an
 | 
			
		||||
   operation that fires independently for each physical row, you
 | 
			
		||||
   probably want to use a trigger, not a rule.  More information about
 | 
			
		||||
   the rules system is in <xref linkend="rules">.
 | 
			
		||||
  </para>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATERULE-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2001-11-06</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Rules and Views
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    Presently, ON SELECT rules must be unconditional INSTEAD rules and must
 | 
			
		||||
    have actions that consist of a single SELECT query.  Thus, an ON SELECT
 | 
			
		||||
    rule effectively turns the table into a view, whose visible
 | 
			
		||||
    contents are the rows returned by the rule's SELECT query rather than
 | 
			
		||||
    whatever had been stored in the table (if anything).  It is considered
 | 
			
		||||
    better style to write a CREATE VIEW command than to create a real table
 | 
			
		||||
    and define an ON SELECT rule for it.
 | 
			
		||||
   </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Presently, <literal>ON SELECT</literal> rules must be unconditional
 | 
			
		||||
   <literal>INSTEAD</literal> rules and must have actions that consist
 | 
			
		||||
   of a single <command>SELECT</command> command.  Thus, an
 | 
			
		||||
   <literal>ON SELECT</literal> rule effectively turns the table into
 | 
			
		||||
   a view, whose visible contents are the rows returned by the rule's
 | 
			
		||||
   <command>SELECT</command> command rather than whatever had been
 | 
			
		||||
   stored in the table (if anything).  It is considered better style
 | 
			
		||||
   to write a <command>CREATE VIEW</command> command than to create a
 | 
			
		||||
   real table and define an <literal>ON SELECT</literal> rule for it.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <xref linkend="sql-createview" endterm="sql-createview-title"> creates a dummy table (with no underlying
 | 
			
		||||
    storage) and associates an ON SELECT rule with it.  The system will not
 | 
			
		||||
    allow updates to the view, since it knows there is no real table there.
 | 
			
		||||
    You can create the
 | 
			
		||||
    illusion of an updatable view by defining ON INSERT, ON UPDATE, and
 | 
			
		||||
    ON DELETE rules (or any subset of those that's sufficient
 | 
			
		||||
    for your purposes) to replace update actions on the view with
 | 
			
		||||
    appropriate updates on other tables.
 | 
			
		||||
   </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   You can create the illusion of an updatable view by defining
 | 
			
		||||
   <literal>ON INSERT</literal>, <literal>ON UPDATE</literal>, and
 | 
			
		||||
   <literal>ON DELETE</literal> rules (or any subset of those that's
 | 
			
		||||
   sufficient for your purposes) to replace update actions on the view
 | 
			
		||||
   with appropriate updates on other tables.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    There is a catch if you try to use conditional
 | 
			
		||||
    rules for view updates: there <emphasis>must</> be an unconditional
 | 
			
		||||
    INSTEAD rule for each action you wish to allow on the view.  If the
 | 
			
		||||
    rule is conditional, or is not INSTEAD, then the system will still reject
 | 
			
		||||
    attempts to perform the update action, because it thinks it might end up
 | 
			
		||||
    trying to perform the action on the dummy table in some cases.
 | 
			
		||||
    If you want to
 | 
			
		||||
    handle all the useful cases in conditional rules, you can; just add an
 | 
			
		||||
    unconditional DO INSTEAD NOTHING rule to ensure that the system
 | 
			
		||||
    understands it will never be called on to update the dummy table.  Then
 | 
			
		||||
    make the conditional rules non-INSTEAD; in the cases where they fire,
 | 
			
		||||
    they add to the default INSTEAD NOTHING action.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   There is a catch if you try to use conditional rules for view
 | 
			
		||||
   updates: there <emphasis>must</> be an unconditional
 | 
			
		||||
   <literal>INSTEAD</literal> rule for each action you wish to allow
 | 
			
		||||
   on the view.  If the rule is conditional, or is not
 | 
			
		||||
   <literal>INSTEAD</literal>, then the system will still reject
 | 
			
		||||
   attempts to perform the update action, because it thinks it might
 | 
			
		||||
   end up trying to perform the action on the dummy table of the view
 | 
			
		||||
   in some cases.  If you want to handle all the useful cases in
 | 
			
		||||
   conditional rules, you can; just add an unconditional <literal>DO
 | 
			
		||||
   INSTEAD NOTHING</literal> rule to ensure that the system
 | 
			
		||||
   understands it will never be called on to update the dummy table.
 | 
			
		||||
   Then make the conditional rules not <literal>INSTEAD</literal>; in
 | 
			
		||||
   the cases where they are applied, they add to the default
 | 
			
		||||
   <literal>INSTEAD NOTHING</literal> action.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATERULE-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2001-01-05</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    You must have rule definition access to a table in order
 | 
			
		||||
    to define a rule on it. Use <command>GRANT</command>
 | 
			
		||||
    and <command>REVOKE</command> to change permissions.
 | 
			
		||||
   </para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    It is very important to take care to avoid circular rules.
 | 
			
		||||
    For example, though each
 | 
			
		||||
    of the following two rule definitions are accepted by
 | 
			
		||||
    <productname>PostgreSQL</productname>, the
 | 
			
		||||
    select command will cause <productname>PostgreSQL</productname> to 
 | 
			
		||||
    report an error because the query cycled too many times:
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of a rule to create.  This must be distinct from the
 | 
			
		||||
      name of any other rule for the same table.  Multiple rules on
 | 
			
		||||
      the same table and same event type are applied in alphabetical
 | 
			
		||||
      name order.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">event</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The even is one of <literal>SELECT</literal>,
 | 
			
		||||
      <literal>INSERT</literal>, <literal>UPDATE</literal>, or
 | 
			
		||||
      <literal>DELETE</literal>.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">table</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of the table or view the
 | 
			
		||||
      rule applies to.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">condition</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Any SQL conditional expression (returning <type>boolean</type>).
 | 
			
		||||
      The condition expression may not refer to any tables except
 | 
			
		||||
      <literal>NEW</literal> and <literal>OLD</literal>, and may not
 | 
			
		||||
      contain aggregate functions.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">command</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The command or commands that make up the rule action.  Valid
 | 
			
		||||
      commands are <literal>SELECT</literal>,
 | 
			
		||||
      <literal>INSERT</literal>, <literal>UPDATE</literal>,
 | 
			
		||||
      <literal>DELETE</literal>, or <literal>NOTIFY</literal>.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Within <replaceable class="parameter">condition</replaceable> and
 | 
			
		||||
   <replaceable class="parameter">command</replaceable>, the special
 | 
			
		||||
   table names <literal>NEW</literal> and <literal>OLD</literal> may
 | 
			
		||||
   be used to refer to values in the referenced table.
 | 
			
		||||
   <literal>NEW</literal> is valid in <literal>ON INSERT</literal> and
 | 
			
		||||
   <literal>ON UPDATE</literal> rules to refer to the new row being
 | 
			
		||||
   inserted or updated.  <literal>OLD</literal> is valid in
 | 
			
		||||
   <literal>ON UPDATE</literal> and <literal>ON DELETE</literal> rules
 | 
			
		||||
   to refer to the existing row being updated or deleted.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE RULE</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the rule was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   You must have the privilege <literal>RULE</literal> on a table to
 | 
			
		||||
   be allowed to define a rule on it.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   It is very important to take care to avoid circular rules.  For
 | 
			
		||||
   example, though each of the following two rule definitions are
 | 
			
		||||
   accepted by <productname>PostgreSQL</productname>, the
 | 
			
		||||
   <command>SELECT</command> command would cause
 | 
			
		||||
   <productname>PostgreSQL</productname> to report an error because
 | 
			
		||||
   the query cycled too many times:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE RULE "_RETURN" AS
 | 
			
		||||
    ON SELECT TO emp
 | 
			
		||||
    ON SELECT TO t1
 | 
			
		||||
    DO INSTEAD 
 | 
			
		||||
	SELECT * FROM toyemp;
 | 
			
		||||
	SELECT * FROM t2;
 | 
			
		||||
 | 
			
		||||
CREATE RULE "_RETURN" AS
 | 
			
		||||
    ON SELECT TO toyemp
 | 
			
		||||
    ON SELECT TO t2
 | 
			
		||||
    DO INSTEAD 
 | 
			
		||||
	SELECT * FROM emp;
 | 
			
		||||
	SELECT * FROM t1;
 | 
			
		||||
 | 
			
		||||
SELECT * FROM t1;
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
      This attempt to select from <literal>EMP</literal> will cause
 | 
			
		||||
      <productname>PostgreSQL</productname> to issue an error
 | 
			
		||||
      because the queries cycled too many times:
 | 
			
		||||
 | 
			
		||||
 <programlisting>
 | 
			
		||||
SELECT * FROM emp;
 | 
			
		||||
</programlisting>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Presently, if a rule contains a NOTIFY query, the NOTIFY will be executed
 | 
			
		||||
    unconditionally --- that is, the NOTIFY will be issued even if there are
 | 
			
		||||
    not any rows that the rule should apply to.  For example, in
 | 
			
		||||
      <programlisting>
 | 
			
		||||
  <para>
 | 
			
		||||
   Presently, if a rule action contains a <command>NOTIFY</command>
 | 
			
		||||
   command, the <command>NOTIFY</command> command will be executed
 | 
			
		||||
   unconditionally, that is, the <command>NOTIFY</command> will be
 | 
			
		||||
   issued even if there are not any rows that the rule should apply
 | 
			
		||||
   to.  For example, in
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE RULE notify_me AS ON UPDATE TO mytable DO NOTIFY mytable;
 | 
			
		||||
 | 
			
		||||
UPDATE mytable SET name = 'foo' WHERE id = 42;
 | 
			
		||||
      </programlisting>
 | 
			
		||||
    one NOTIFY event will be sent during the UPDATE, whether or not there
 | 
			
		||||
    are any rows with id = 42.  This is an implementation restriction that
 | 
			
		||||
    may be fixed in future releases.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
</programlisting>
 | 
			
		||||
   one <command>NOTIFY</command> event will be sent during the
 | 
			
		||||
   <command>UPDATE</command>, whether or not there are any rows with
 | 
			
		||||
   <literal>id = 42</literal>.  This is an implementation restriction
 | 
			
		||||
   that may be fixed in future releases.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATERULE-4">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATERULE-5">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE RULE</command> is a <productname>PostgreSQL</productname>
 | 
			
		||||
    language extension.
 | 
			
		||||
    There is no <command>CREATE RULE</command> statement in <acronym>SQL92</acronym>.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE RULE</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> language extension, as is the
 | 
			
		||||
   entire rules system.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_schema.sgml,v 1.4 2003/02/03 15:56:50 momjian Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_schema.sgml,v 1.5 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,25 +8,51 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createschema-title">CREATE SCHEMA</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE SCHEMA
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new schema
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE SCHEMA</refname>
 | 
			
		||||
  <refpurpose>define a new schema</refpurpose>
 | 
			
		||||
 </refnamediv> 
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE SCHEMA <replaceable class="parameter">schemaname</replaceable> [ AUTHORIZATION <replaceable class="parameter">username</replaceable> ] [ <replaceable class="parameter">schema_element</replaceable> [ ... ] ]
 | 
			
		||||
CREATE SCHEMA AUTHORIZATION <replaceable class="parameter">username</replaceable> [ <replaceable class="parameter">schema_element</replaceable> [ ... ] ]
 | 
			
		||||
  </synopsis>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE SCHEMA</command> will enter a new schema
 | 
			
		||||
   into the current database.
 | 
			
		||||
   The schema name must be distinct from the name of any existing schema
 | 
			
		||||
   in the current database.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   A schema is essentially a namespace:
 | 
			
		||||
   it contains named objects (tables, data types, functions, and operators)
 | 
			
		||||
   whose names may duplicate those of other objects existing in other
 | 
			
		||||
   schemas.  Named objects are accessed either by <quote>qualifying</>
 | 
			
		||||
   their names with the schema name as a prefix, or by setting a search
 | 
			
		||||
   path that includes the desired schema(s).  Unqualified objects are
 | 
			
		||||
   created in the current schema (the one at the front of the search path,
 | 
			
		||||
   which can be determined with the function <function>current_schema</function>).
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Optionally, <command>CREATE SCHEMA</command> can include subcommands
 | 
			
		||||
   to create objects within the new schema.  The subcommands are treated
 | 
			
		||||
   essentially the same as separate commands issued after creating the
 | 
			
		||||
   schema, except that if the <literal>AUTHORIZATION</> clause is used,
 | 
			
		||||
   all the created objects will be owned by that user.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESCHEMA-1">
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
@ -63,164 +89,112 @@ CREATE SCHEMA AUTHORIZATION <replaceable class="parameter">username</replaceable
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESCHEMA-2">
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE SCHEMA
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the command is successful.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR:  namespace "<replaceable class="parameter">schemaname</replaceable>" already exists
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If the schema specified already exists.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATESCHEMA-1">
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE SCHEMA</command> will enter a new schema
 | 
			
		||||
   into the current database.
 | 
			
		||||
   The schema name must be distinct from the name of any existing schema
 | 
			
		||||
   in the current database.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   A schema is essentially a namespace:
 | 
			
		||||
   it contains named objects (tables, data types, functions, and operators)
 | 
			
		||||
   whose names may duplicate those of other objects existing in other
 | 
			
		||||
   schemas.  Named objects are accessed either by <quote>qualifying</>
 | 
			
		||||
   their names with the schema name as a prefix, or by setting a search
 | 
			
		||||
   path that includes the desired schema(s).  Unqualified objects are
 | 
			
		||||
   created in the current schema (the one at the front of the search path; 
 | 
			
		||||
   see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Optionally, <command>CREATE SCHEMA</command> can include subcommands
 | 
			
		||||
   to create objects within the new schema.  The subcommands are treated
 | 
			
		||||
   essentially the same as separate commands issued after creating the
 | 
			
		||||
   schema, except that if the <literal>AUTHORIZATION</> clause is used,
 | 
			
		||||
   all the created objects will be owned by that user.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESCHEMA-3">
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    To create a schema, the invoking user must have <literal>CREATE</>
 | 
			
		||||
    privilege for the current database.  (Of course, superusers bypass
 | 
			
		||||
    this check.)
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Use <command>DROP SCHEMA</command> to remove a schema.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATESCHEMA-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Examples
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a schema:
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <programlisting>
 | 
			
		||||
CREATE SCHEMA myschema;
 | 
			
		||||
  </programlisting>
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE SCHEMA</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the schema was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>ERROR:  namespace "<replaceable class="parameter">schemaname</replaceable>" already exists</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the schema specified already exists.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To create a schema, the invoking user must have <literal>CREATE</>
 | 
			
		||||
   privilege for the current database.  (Of course, superusers bypass
 | 
			
		||||
   this check.)
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a schema for user <literal>joe</> --- the schema will also
 | 
			
		||||
   be named <literal>joe</>:
 | 
			
		||||
   Use <command>DROP SCHEMA</command> to remove a schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
  <programlisting>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a schema:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE SCHEMA myschema;
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a schema for user <literal>joe</>; the schema will also be
 | 
			
		||||
   named <literal>joe</>:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE SCHEMA AUTHORIZATION joe;
 | 
			
		||||
  </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a schema and create a table and view within it:
 | 
			
		||||
 | 
			
		||||
  <programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE SCHEMA hollywood
 | 
			
		||||
    CREATE TABLE films (title text, release date, awards text[])
 | 
			
		||||
    CREATE VIEW winners AS
 | 
			
		||||
        SELECT title, release FROM films WHERE awards IS NOT NULL;
 | 
			
		||||
  </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
   Notice that the individual subcommands do not end with semicolons.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The following is an equivalent way of accomplishing the same result:
 | 
			
		||||
  <programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE SCHEMA hollywood;
 | 
			
		||||
CREATE TABLE hollywood.films (title text, release date, awards text[]);
 | 
			
		||||
CREATE VIEW hollywood.winners AS
 | 
			
		||||
    SELECT title, release FROM hollywood.films WHERE awards IS NOT NULL;
 | 
			
		||||
  </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATESCHEMA-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESCHEMA-4">
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   The SQL standard allows a <literal>DEFAULT CHARACTER SET</> clause
 | 
			
		||||
   in <command>CREATE SCHEMA</command>, as well as more subcommand
 | 
			
		||||
   types than are presently accepted by
 | 
			
		||||
   <productname>PostgreSQL</productname>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    SQL92 allows a <literal>DEFAULT CHARACTER SET</> clause in
 | 
			
		||||
    <command>CREATE SCHEMA</command>, as well as more subcommand types
 | 
			
		||||
    than are presently accepted by <productname>PostgreSQL</productname>.
 | 
			
		||||
   </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   The SQL standard specifies that the subcommands in <command>CREATE
 | 
			
		||||
   SCHEMA</command> may appear in any order.  The present
 | 
			
		||||
   <productname>PostgreSQL</productname> implementation does not
 | 
			
		||||
   handle all cases of forward references in subcommands; it may
 | 
			
		||||
   sometimes be necessary to reorder the subcommands to avoid forward
 | 
			
		||||
   references.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    SQL92 specifies that the subcommands in <command>CREATE SCHEMA</command>
 | 
			
		||||
    may appear in any order.  The present
 | 
			
		||||
    <productname>PostgreSQL</productname> implementation does not handle all
 | 
			
		||||
    cases of forward references in subcommands; it may sometimes be necessary
 | 
			
		||||
    to reorder the subcommands to avoid forward references.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    In SQL92, the owner of a schema always owns all objects within it.
 | 
			
		||||
    <productname>PostgreSQL</productname> allows schemas to contain objects
 | 
			
		||||
    owned by users other than the schema owner.  This can happen only if the
 | 
			
		||||
    schema owner grants <literal>CREATE</> rights on his schema to someone
 | 
			
		||||
    else.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   According to the SQL standard, the owner of a schema always owns
 | 
			
		||||
   all objects within it.  <productname>PostgreSQL</productname>
 | 
			
		||||
   allows schemas to contain objects owned by users other than the
 | 
			
		||||
   schema owner.  This can happen only if the schema owner grants the
 | 
			
		||||
   <literal>CREATE</> privilege on his schema to someone else.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_sequence.sgml,v 1.32 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_sequence.sgml,v 1.33 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,248 +8,36 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createsequence-title">CREATE SEQUENCE</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE SEQUENCE
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new sequence generator
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE SEQUENCE</refname>
 | 
			
		||||
  <refpurpose>define a new sequence generator</refpurpose>
 | 
			
		||||
 </refnamediv> 
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>1999-07-20</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE [ TEMPORARY | TEMP ] SEQUENCE <replaceable class="parameter">seqname</replaceable> [ INCREMENT [ BY ] <replaceable class="parameter">increment</replaceable> ]
 | 
			
		||||
    [ MINVALUE <replaceable class="parameter">minvalue</replaceable> | NO MINVALUE ] [ MAXVALUE <replaceable class="parameter">maxvalue</replaceable> | NO MAXVALUE ]
 | 
			
		||||
    [ START [ WITH ] <replaceable class="parameter">start</replaceable> ] [ CACHE <replaceable class="parameter">cache</replaceable> ] [ [ NO ] CYCLE ]
 | 
			
		||||
  </synopsis>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESEQUENCE-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>TEMPORARY or TEMP</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If specified, the sequence object is created only for this session,
 | 
			
		||||
	and is automatically dropped on session exit.
 | 
			
		||||
	Existing permanent sequences with the same name are not visible
 | 
			
		||||
	(in this session) while the temporary sequence exists, unless
 | 
			
		||||
	they are referenced with schema-qualified names.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">seqname</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name (optionally schema-qualified) of a sequence to be created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">increment</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The
 | 
			
		||||
	<option>INCREMENT BY <replaceable class="parameter">increment</replaceable></option>
 | 
			
		||||
	clause is optional. A positive value will make an
 | 
			
		||||
	ascending sequence, a negative one a descending sequence.
 | 
			
		||||
	The default value is one (1).
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">minvalue</replaceable></term>
 | 
			
		||||
      <term>NO MINVALUE</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The optional clause <option>MINVALUE
 | 
			
		||||
	 <replaceable class="parameter">minvalue</replaceable></option>
 | 
			
		||||
	determines the minimum value
 | 
			
		||||
	a sequence can generate. If this clause is not supplied or <option>NO MINVALUE</option>
 | 
			
		||||
    is specified, then defaults will be used.  The defaults are 1 and -2^63-1 for
 | 
			
		||||
	ascending and descending sequences, respectively.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">maxvalue</replaceable></term>
 | 
			
		||||
      <term>NO MAXVALUE</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The optional clause <option>MAXVALUE
 | 
			
		||||
	 <replaceable class="parameter">maxvalue</replaceable></option>
 | 
			
		||||
	determines the maximum
 | 
			
		||||
	value for the sequence. If this clause is not supplied or 
 | 
			
		||||
    <option>NO MAXVALUE</option> is specified, then default values will be used.
 | 
			
		||||
    The defaults are 2^63-1 and -1 for ascending and descending sequences, respectively.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">start</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The optional <option>START WITH
 | 
			
		||||
	 <replaceable class="parameter">start</replaceable>
 | 
			
		||||
	 clause</option> enables the sequence to begin anywhere.
 | 
			
		||||
	The default starting value is
 | 
			
		||||
	<replaceable class="parameter">minvalue</replaceable>
 | 
			
		||||
	for ascending sequences and
 | 
			
		||||
	<replaceable class="parameter">maxvalue</replaceable>
 | 
			
		||||
	for descending ones.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">cache</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The <option>CACHE <replaceable class="parameter">cache</replaceable></option> option
 | 
			
		||||
	enables sequence numbers to be preallocated
 | 
			
		||||
	and stored in memory for faster access. The  minimum
 | 
			
		||||
	value is 1 (only one value can be generated at a time, i.e., no cache)
 | 
			
		||||
	and this is also the default.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>CYCLE</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The optional <option>CYCLE</option> keyword may be used to enable
 | 
			
		||||
	the sequence to wrap around when the
 | 
			
		||||
	<replaceable class="parameter">maxvalue</replaceable> or
 | 
			
		||||
	<replaceable class="parameter">minvalue</replaceable> has been
 | 
			
		||||
	reached by
 | 
			
		||||
	an ascending or descending sequence respectively. If the limit is
 | 
			
		||||
	reached, the next number generated will be the
 | 
			
		||||
	<replaceable class="parameter">minvalue</replaceable> or
 | 
			
		||||
	<replaceable class="parameter">maxvalue</replaceable>,
 | 
			
		||||
	respectively.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
	 <varlistentry>
 | 
			
		||||
	  <term>NO CYCLE</term>
 | 
			
		||||
	  <listitem>
 | 
			
		||||
	   <para>
 | 
			
		||||
	If the optional <option>NO CYCLE</option> keyword is specified, any
 | 
			
		||||
	calls to <function>nextval</function> after the sequence has reached
 | 
			
		||||
	its maximum value will return an error.  If neither
 | 
			
		||||
	<option>CYCLE</option> or <option>NO CYCLE</option> are specified,
 | 
			
		||||
	<option>NO CYCLE</option> is the default.
 | 
			
		||||
	   </para>
 | 
			
		||||
	  </listitem>
 | 
			
		||||
	</varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESEQUENCE-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE SEQUENCE
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the command is successful.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR:  Relation '<replaceable class="parameter">seqname</replaceable>' already exists
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If the sequence specified already exists.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR:  DefineSequence: MINVALUE (<replaceable class="parameter">start</replaceable>) can't be >= MAXVALUE (<replaceable class="parameter">max</replaceable>)
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If the specified starting value is out of range.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR:  DefineSequence: START value (<replaceable class="parameter">start</replaceable>) can't be < MINVALUE (<replaceable class="parameter">min</replaceable>)
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If the specified starting value is out of range.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR:  DefineSequence: MINVALUE (<replaceable class="parameter">min</replaceable>) can't be >= MAXVALUE (<replaceable class="parameter">max</replaceable>)
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	If the minimum and maximum values are inconsistent.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATESEQUENCE-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>1998-09-11</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE SEQUENCE</command> will enter a new sequence number generator
 | 
			
		||||
   into the current database. This involves creating and initializing a
 | 
			
		||||
   new single-row
 | 
			
		||||
   table with the name <replaceable class="parameter">seqname</replaceable>.
 | 
			
		||||
   The generator will be owned by the user issuing the command.
 | 
			
		||||
   <command>CREATE SEQUENCE</command> creates a new sequence number
 | 
			
		||||
   generator.  This involves creating and initializing a new special
 | 
			
		||||
   single-row table with the name <replaceable
 | 
			
		||||
   class="parameter">seqname</replaceable>.  The generator will be
 | 
			
		||||
   owned by the user issuing the command.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given then the sequence is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   TEMP sequences exist in a special schema, so a schema name may not be
 | 
			
		||||
   given when creating a TEMP sequence.
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
   Temporary sequences exist in a special schema, so a schema name may not be
 | 
			
		||||
   given when creating a temporary sequence.
 | 
			
		||||
   The sequence name must be distinct from the name of any other sequence,
 | 
			
		||||
   table, index, or view in the same schema.
 | 
			
		||||
  </para>
 | 
			
		||||
@ -257,7 +45,7 @@ ERROR:  DefineSequence: MINVALUE (<replaceable class="parameter">min</replaceabl
 | 
			
		||||
  <para>
 | 
			
		||||
   After a sequence is created, you use the functions
 | 
			
		||||
   <function>nextval</function>,
 | 
			
		||||
   <function>currval</function> and
 | 
			
		||||
   <function>currval</function>, and
 | 
			
		||||
   <function>setval</function>
 | 
			
		||||
   to operate on the sequence.  These functions are documented in
 | 
			
		||||
   <xref linkend="functions-sequence">.
 | 
			
		||||
@ -266,132 +54,293 @@ ERROR:  DefineSequence: MINVALUE (<replaceable class="parameter">min</replaceabl
 | 
			
		||||
  <para>
 | 
			
		||||
   Although you cannot update a sequence directly, you can use a query like
 | 
			
		||||
 | 
			
		||||
   <programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
SELECT * FROM <replaceable>seqname</replaceable>;
 | 
			
		||||
   </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
   to examine the parameters and current state of a sequence.  In particular,
 | 
			
		||||
   the <literal>last_value</> field of the sequence shows the last value
 | 
			
		||||
   allocated by any backend process.  (Of course, this value may be obsolete
 | 
			
		||||
   by the time it's printed, if other processes are actively doing
 | 
			
		||||
   allocated by any session.  (Of course, this value may be obsolete
 | 
			
		||||
   by the time it's printed, if other sessions are actively doing
 | 
			
		||||
   <function>nextval</> calls.)
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <caution>
 | 
			
		||||
   <para>
 | 
			
		||||
    Unexpected results may be obtained if a <replaceable class="parameter">cache</replaceable> setting greater than one
 | 
			
		||||
    is used for a sequence object that will be used concurrently by multiple
 | 
			
		||||
    backends.  Each backend will allocate and cache successive sequence values
 | 
			
		||||
    during one access to the sequence object and increase the sequence
 | 
			
		||||
    object's <literal>last_value</> accordingly.  Then, the next <replaceable class="parameter">cache</replaceable>-1 uses of <function>nextval</>
 | 
			
		||||
    within that backend simply return the preallocated values without touching
 | 
			
		||||
    the shared object.  So, any numbers allocated but not used within a session
 | 
			
		||||
    will be lost when that session ends.  Furthermore, although multiple backends are guaranteed to
 | 
			
		||||
    allocate distinct sequence values, the values may be generated out of
 | 
			
		||||
    sequence when all the backends are considered.  (For example, with a <replaceable class="parameter">cache</replaceable>
 | 
			
		||||
    setting of 10, backend A might reserve values 1..10 and return <function>nextval</function>=1, 
 | 
			
		||||
    then
 | 
			
		||||
    backend B might reserve values 11..20 and return <function>nextval</function>=11 before backend
 | 
			
		||||
    A has generated <literal>nextval</literal>=2.)  Thus, with a <replaceable class="parameter">cache</replaceable> setting of one it is safe
 | 
			
		||||
    to assume that <function>nextval</> values are generated sequentially; with a <replaceable class="parameter">cache</replaceable>
 | 
			
		||||
    setting greater than one you should only assume that the <function>nextval</> values
 | 
			
		||||
    are all distinct, not that they are generated purely sequentially.
 | 
			
		||||
    Also, <literal>last_value</> will reflect the latest value reserved by any backend,
 | 
			
		||||
    whether or not it has yet been returned by <function>nextval</>.
 | 
			
		||||
    Another consideration is that a <function>setval</> executed on such a sequence
 | 
			
		||||
    will not be noticed by other backends until they have used up any
 | 
			
		||||
    preallocated values they have cached.
 | 
			
		||||
   </para>
 | 
			
		||||
  </caution>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESEQUENCE-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Use <command>DROP SEQUENCE</command> to remove a sequence.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Sequences are based on <type>bigint</> arithmetic, so the range cannot
 | 
			
		||||
    exceed the range of an eight-byte integer
 | 
			
		||||
    (-9223372036854775808 to 9223372036854775807).  On some older platforms,
 | 
			
		||||
    there may be no compiler support for eight-byte integers, in which case
 | 
			
		||||
    sequences use regular <type>integer</> arithmetic (range
 | 
			
		||||
    -2147483648 to +2147483647).
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    When <replaceable class="parameter">cache</replaceable> is greater than
 | 
			
		||||
    one, each backend uses its own cache to store preallocated numbers.
 | 
			
		||||
    Numbers that are cached but not used in the current session will be
 | 
			
		||||
    lost, resulting in <quote>holes</quote> in the sequence.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATESEQUENCE-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>TEMPORARY</literal> or <literal>TEMP</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      If specified, the sequence object is created only for this
 | 
			
		||||
      session, and is automatically dropped on session exit.  Existing
 | 
			
		||||
      permanent sequences with the same name are not visible (in this
 | 
			
		||||
      session) while the temporary sequence exists, unless they are
 | 
			
		||||
      referenced with schema-qualified names.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">seqname</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of the sequence to be created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">increment</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The optional clause <literal>INCREMENT BY <replaceable
 | 
			
		||||
      class="parameter">increment</replaceable></literal> specified,
 | 
			
		||||
      which value is added to the current sequence value to create a
 | 
			
		||||
      new value.  A positive value will make an ascending sequence, a
 | 
			
		||||
      negative one a descending sequence.  The default value is 1.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">minvalue</replaceable></term>
 | 
			
		||||
    <term><literal>NO MINVALUE</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The optional clause <literal>MINVALUE <replaceable
 | 
			
		||||
      class="parameter">minvalue</replaceable></literal> determines
 | 
			
		||||
      the minimum value a sequence can generate. If this clause is not
 | 
			
		||||
      supplied or <option>NO MINVALUE</option> is specified, then
 | 
			
		||||
      defaults will be used.  The defaults are 1 and
 | 
			
		||||
      -2<superscript>63</>-1 for ascending and descending sequences,
 | 
			
		||||
      respectively.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">maxvalue</replaceable></term>
 | 
			
		||||
    <term><literal>NO MAXVALUE</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The optional clause <literal>MAXVALUE <replaceable
 | 
			
		||||
      class="parameter">maxvalue</replaceable></literal> determines
 | 
			
		||||
      the maximum value for the sequence. If this clause is not
 | 
			
		||||
      supplied or <option>NO MAXVALUE</option> is specified, then
 | 
			
		||||
      default values will be used.  The defaults are
 | 
			
		||||
      2<superscript>63</>-1 and -1 for ascending and descending
 | 
			
		||||
      sequences, respectively.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">start</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The optional clause <literal>START WITH <replaceable
 | 
			
		||||
      class="parameter">start</replaceable> </literal> allows the
 | 
			
		||||
      sequence to begin anywhere.  The default starting value is
 | 
			
		||||
      <replaceable class="parameter">minvalue</replaceable> for
 | 
			
		||||
      ascending sequences and <replaceable
 | 
			
		||||
      class="parameter">maxvalue</replaceable> for descending ones.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">cache</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The optional clause <literal>CACHE <replaceable
 | 
			
		||||
      class="parameter">cache</replaceable></literal> specifies how
 | 
			
		||||
      many sequence numbers are to be preallocated and stored in
 | 
			
		||||
      memory for faster access. The minimum value is 1 (only one value
 | 
			
		||||
      can be generated at a time, i.e., no cache), and this is also the
 | 
			
		||||
      default.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>CYCLE</literal></term>
 | 
			
		||||
    <term><literal>NO CYCLE</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The <literal>CYCLE</literal> option allows the sequence to wrap
 | 
			
		||||
      around when the <replaceable
 | 
			
		||||
      class="parameter">maxvalue</replaceable> or <replaceable
 | 
			
		||||
      class="parameter">minvalue</replaceable> has been reached by an
 | 
			
		||||
      ascending or descending sequence respectively. If the limit is
 | 
			
		||||
      reached, the next number generated will be the <replaceable
 | 
			
		||||
      class="parameter">minvalue</replaceable> or <replaceable
 | 
			
		||||
      class="parameter">maxvalue</replaceable>, respectively.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      If <literal>NO CYCLE</literal> is specified, any calls to
 | 
			
		||||
      <function>nextval</function> after the sequence has reached its
 | 
			
		||||
      maximum value will return an error.  If neither
 | 
			
		||||
      <literal>CYCLE</literal> or <literal>NO CYCLE</literal> are
 | 
			
		||||
      specified, <literal>NO CYCLE</literal> is the default.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE SEQUENCE</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the sequence was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>ERROR:  Relation '<replaceable class="parameter">seqname</replaceable>' already exists</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      A sequence, table, view, or index of the specified name already exists.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>ERROR:  DefineSequence: MINVALUE (<replaceable class="parameter">start</replaceable>) can't be >= MAXVALUE (<replaceable class="parameter">max</replaceable>)</computeroutput></term>
 | 
			
		||||
    <term><computeroutput>ERROR:  DefineSequence: START value (<replaceable class="parameter">start</replaceable>) can't be < MINVALUE (<replaceable class="parameter">min</replaceable>)</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The specified starting value is out of range.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>ERROR:  DefineSequence: MINVALUE (<replaceable class="parameter">min</replaceable>) can't be >= MAXVALUE (<replaceable class="parameter">max</replaceable>)</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The minimum and maximum values are inconsistent.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use <command>DROP SEQUENCE</command> to remove a sequence.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Sequences are based on <type>bigint</> arithmetic, so the range
 | 
			
		||||
   cannot exceed the range of an eight-byte integer
 | 
			
		||||
   (-9223372036854775808 to 9223372036854775807).  On some older
 | 
			
		||||
   platforms, there may be no compiler support for eight-byte
 | 
			
		||||
   integers, in which case sequences use regular <type>integer</>
 | 
			
		||||
   arithmetic (range -2147483648 to +2147483647).
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Unexpected results may be obtained if a <replaceable
 | 
			
		||||
   class="parameter">cache</replaceable> setting greater than one is
 | 
			
		||||
   used for a sequence object that will be used concurrently by
 | 
			
		||||
   multiple sessions.  Each session will allocate and cache successive
 | 
			
		||||
   sequence values during one access to the sequence object and
 | 
			
		||||
   increase the sequence object's <literal>last_value</> accordingly.
 | 
			
		||||
   Then, the next <replaceable class="parameter">cache</replaceable>-1
 | 
			
		||||
   uses of <function>nextval</> within that session simply return the
 | 
			
		||||
   preallocated values without touching the sequence object.  So, any
 | 
			
		||||
   numbers allocated but not used within a session will be lost when
 | 
			
		||||
   that session ends, resulting in <quote>holes</quote> in the
 | 
			
		||||
   sequence.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Furthermore, although multiple sessions are guaranteed to allocate
 | 
			
		||||
   distinct sequence values, the values may be generated out of
 | 
			
		||||
   sequence when all the sessions are considered.  FFor example, with
 | 
			
		||||
   a <replaceable class="parameter">cache</replaceable> setting of 10,
 | 
			
		||||
   session A might reserve values 1..10 and return
 | 
			
		||||
   <function>nextval</function>=1, then session B might reserve values
 | 
			
		||||
   11..20 and return <function>nextval</function>=11 before session A
 | 
			
		||||
   has generated <literal>nextval</literal>=2.  Thus, with a
 | 
			
		||||
   <replaceable class="parameter">cache</replaceable> setting of one
 | 
			
		||||
   it is safe to assume that <function>nextval</> values are generated
 | 
			
		||||
   sequentially; with a <replaceable
 | 
			
		||||
   class="parameter">cache</replaceable> setting greater than one you
 | 
			
		||||
   should only assume that the <function>nextval</> values are all
 | 
			
		||||
   distinct, not that they are generated purely sequentially.  Also,
 | 
			
		||||
   <literal>last_value</> will reflect the latest value reserved by
 | 
			
		||||
   any session, whether or not it has yet been returned by
 | 
			
		||||
   <function>nextval</>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Another consideration is that a <function>setval</> executed on
 | 
			
		||||
   such a sequence will not be noticed by other sessions until they
 | 
			
		||||
   have used up any preallocated values they have cached.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Create an ascending sequence called <literal>serial</literal>, starting at 101:
 | 
			
		||||
  </para>
 | 
			
		||||
  <programlisting>
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE SEQUENCE serial START 101;
 | 
			
		||||
  </programlisting>
 | 
			
		||||
  <para>
 | 
			
		||||
   Select the next number from this sequence:
 | 
			
		||||
   <programlisting>
 | 
			
		||||
SELECT nextval('serial');
 | 
			
		||||
    
 | 
			
		||||
nextval
 | 
			
		||||
-------
 | 
			
		||||
    114
 | 
			
		||||
   </programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   Use this sequence in an INSERT:
 | 
			
		||||
   <programlisting>
 | 
			
		||||
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
 | 
			
		||||
   </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Update the sequence value after a COPY FROM:
 | 
			
		||||
   <programlisting>
 | 
			
		||||
   Select the next number from this sequence:
 | 
			
		||||
<programlisting>
 | 
			
		||||
SELECT nextval('serial');
 | 
			
		||||
    
 | 
			
		||||
 nextval
 | 
			
		||||
---------
 | 
			
		||||
     114
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Use this sequence in an <command>INSERT</command> command:
 | 
			
		||||
<programlisting>
 | 
			
		||||
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Update the sequence value after a <command>COPY FROM</command>:
 | 
			
		||||
<programlisting>
 | 
			
		||||
BEGIN;
 | 
			
		||||
    COPY distributors FROM 'input_file';
 | 
			
		||||
    SELECT setval('serial', max(id)) FROM distributors;
 | 
			
		||||
COPY distributors FROM 'input_file';
 | 
			
		||||
SELECT setval('serial', max(id)) FROM distributors;
 | 
			
		||||
END;
 | 
			
		||||
   </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATESEQUENCE-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATESEQUENCE-4">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-11</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE SEQUENCE</command> is a <productname>PostgreSQL</productname>
 | 
			
		||||
    language extension.
 | 
			
		||||
    There is no <command>CREATE SEQUENCE</command> statement
 | 
			
		||||
    in <acronym>SQL92</acronym>.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE SEQUENCE</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> language extension.  There is
 | 
			
		||||
   no <command>CREATE SEQUENCE</command> statement in the SQL
 | 
			
		||||
   standard.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.66 2003/04/14 18:08:58 tgl Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.67 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -29,7 +29,7 @@ where <replaceable class="PARAMETER">column_constraint</replaceable> is:
 | 
			
		||||
[ CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> ]
 | 
			
		||||
{ NOT NULL | NULL | UNIQUE | PRIMARY KEY |
 | 
			
		||||
  CHECK (<replaceable class="PARAMETER">expression</replaceable>) |
 | 
			
		||||
  REFERENCES <replaceable class="PARAMETER">reftable</replaceable> [ ( <replaceable class="PARAMETER">refcolumn</replaceable> ) ] [ MATCH FULL | MATCH PARTIAL ]
 | 
			
		||||
  REFERENCES <replaceable class="PARAMETER">reftable</replaceable> [ ( <replaceable class="PARAMETER">refcolumn</replaceable> ) ] [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
 | 
			
		||||
    [ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ] }
 | 
			
		||||
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
 | 
			
		||||
 | 
			
		||||
@ -40,7 +40,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
  PRIMARY KEY ( <replaceable class="PARAMETER">column_name</replaceable> [, ... ] ) |
 | 
			
		||||
  CHECK ( <replaceable class="PARAMETER">expression</replaceable> ) |
 | 
			
		||||
  FOREIGN KEY ( <replaceable class="PARAMETER">column_name</replaceable> [, ... ] ) REFERENCES <replaceable class="PARAMETER">reftable</replaceable> [ ( <replaceable class="PARAMETER">refcolumn</replaceable> [, ... ] ) ]
 | 
			
		||||
    [ MATCH FULL | MATCH PARTIAL ] [ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ] }
 | 
			
		||||
    [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ] }
 | 
			
		||||
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
 | 
			
		||||
</synopsis>
 | 
			
		||||
  
 | 
			
		||||
@ -58,17 +58,16 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given (for example, <literal>CREATE TABLE
 | 
			
		||||
   myschema.mytable ...</>) then the table is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   TEMP tables exist in a special schema, so a schema name may not be
 | 
			
		||||
   given when creating a TEMP table.
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
   Temporary tables exist in a special schema, so a schema name may not be
 | 
			
		||||
   given when creating a temporary table.
 | 
			
		||||
   The table name must be distinct from the name of any other table,
 | 
			
		||||
   sequence, index, or view in the same schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE TABLE</command> also automatically creates a data
 | 
			
		||||
   type that represents the tuple type (structure type) corresponding
 | 
			
		||||
   type that represents the composite type corresponding
 | 
			
		||||
   to one row of the table.  Therefore, tables cannot have the same
 | 
			
		||||
   name as any existing data type in the same schema.
 | 
			
		||||
  </para>
 | 
			
		||||
@ -81,9 +80,8 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
  <para>
 | 
			
		||||
   The optional constraint clauses specify constraints (or tests) that
 | 
			
		||||
   new or updated rows must satisfy for an insert or update operation
 | 
			
		||||
   to succeed.  A constraint is a named rule: an SQL object which
 | 
			
		||||
   helps define valid sets of values by putting limits on the results
 | 
			
		||||
   of insert, update, or delete operations performed on a table.
 | 
			
		||||
   to succeed.  A constraint is an SQL object that helps define the
 | 
			
		||||
   set of valid values in the table in various ways.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
@ -158,7 +156,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
     <para>
 | 
			
		||||
      The <literal>DEFAULT</> clause assigns a default data value for
 | 
			
		||||
      the column whose column definition it appears within.  The value
 | 
			
		||||
      is any variable-free expression (subselects and cross-references
 | 
			
		||||
      is any variable-free expression (subqueries and cross-references
 | 
			
		||||
      to other columns in the current table are not allowed).  The
 | 
			
		||||
      data type of the default expression must match the data type of the
 | 
			
		||||
      column.
 | 
			
		||||
@ -167,7 +165,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
     <para>
 | 
			
		||||
      The default expression will be used in any insert operation that
 | 
			
		||||
      does not specify a value for the column.  If there is no default
 | 
			
		||||
      for a column, then the default is NULL.
 | 
			
		||||
      for a column, then the default is null.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
@ -212,7 +210,8 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>WITH OIDS</> or <literal>WITHOUT OIDS</></term>
 | 
			
		||||
    <term><literal>WITH OIDS</></term>
 | 
			
		||||
    <term><literal>WITHOUT OIDS</></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      This optional clause specifies whether rows of the new table
 | 
			
		||||
@ -250,7 +249,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
    <term><literal>NOT NULL</></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The column is not allowed to contain NULL values.
 | 
			
		||||
      The column is not allowed to contain null values.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
@ -259,7 +258,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
    <term><literal>NULL</></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The column is allowed to contain NULL values. This is the default.
 | 
			
		||||
      The column is allowed to contain null values. This is the default.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
@ -276,7 +275,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The <literal>UNIQUE</literal> constraint specifies a rule that a
 | 
			
		||||
      The <literal>UNIQUE</literal> constraint specifies that a
 | 
			
		||||
      group of one or more distinct columns of a table may contain
 | 
			
		||||
      only unique values. The behavior of the unique table constraint
 | 
			
		||||
      is the same as that for column constraints, with the additional
 | 
			
		||||
@ -284,7 +283,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      For the purpose of a unique constraint, NULL values are not
 | 
			
		||||
      For the purpose of a unique constraint, null values are not
 | 
			
		||||
      considered equal.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
@ -303,11 +302,11 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The primary key constraint specifies that a column or columns of a table
 | 
			
		||||
      may contain only unique (non-duplicate), non-NULL values.
 | 
			
		||||
      may contain only unique (non-duplicate), nonnull values.
 | 
			
		||||
      Technically, <literal>PRIMARY KEY</literal> is merely a
 | 
			
		||||
      combination of <literal>UNIQUE</> and <literal>NOT NULL</>, but
 | 
			
		||||
      identifying a set of columns as primary key also provides
 | 
			
		||||
      meta-data about the design of the schema, as a primary key
 | 
			
		||||
      metadata about the design of the schema, as a primary key
 | 
			
		||||
      implies that other tables
 | 
			
		||||
      may rely on this set of columns as a unique identifier for rows.
 | 
			
		||||
     </para>
 | 
			
		||||
@ -329,21 +328,19 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
    <term><literal>CHECK (<replaceable class="PARAMETER">expression</replaceable>)</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      <literal>CHECK</> clauses specify integrity constraints or tests
 | 
			
		||||
      which new or updated rows must satisfy for an insert or update
 | 
			
		||||
      operation to succeed. Each constraint must be an expression
 | 
			
		||||
      producing a Boolean result.  A condition appearing within a
 | 
			
		||||
      column definition should reference that column's value only,
 | 
			
		||||
      while a condition appearing as a table constraint may reference
 | 
			
		||||
      multiple columns.
 | 
			
		||||
      The <literal>CHECK</> clause specifies an expression producing a
 | 
			
		||||
      Boolean result which new or updated rows must satisfy for an
 | 
			
		||||
      insert or update operation to succeed.  A check constraint
 | 
			
		||||
      specified as a column constraint should reference that column's
 | 
			
		||||
      value only, while an expression appearing in a table constraint
 | 
			
		||||
      may reference multiple columns.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      Currently, <literal>CHECK</literal> expressions cannot contain
 | 
			
		||||
      subselects nor refer to variables other than columns of the
 | 
			
		||||
      subqueries nor refer to variables other than columns of the
 | 
			
		||||
      current row.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
@ -360,7 +357,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The <literal>REFERENCES</literal> column constraint specifies
 | 
			
		||||
      Theses clauses specify a foreign key constraint, which specifies
 | 
			
		||||
      that a group of one or more columns of the new table must only
 | 
			
		||||
      contain values which match against values in the referenced
 | 
			
		||||
      column(s) <replaceable class="parameter">refcolumn</replaceable>
 | 
			
		||||
@ -374,23 +371,23 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      A value added to these columns is matched against the values of
 | 
			
		||||
      the referenced table and referenced columns using the given
 | 
			
		||||
      match type.  There are three match types: <literal>MATCH
 | 
			
		||||
      FULL</>, <literal>MATCH PARTIAL</>, and a default match type if
 | 
			
		||||
      none is specified. <literal>MATCH FULL</> will not allow one
 | 
			
		||||
      column of a multicolumn foreign key to be NULL unless all
 | 
			
		||||
      foreign key columns are NULL. The default match type allows some
 | 
			
		||||
      foreign key columns to be NULL while other parts of the foreign
 | 
			
		||||
      key are not NULL. <literal>MATCH PARTIAL</> is not yet
 | 
			
		||||
      implemented.
 | 
			
		||||
      A value inserted into these columns is matched against the
 | 
			
		||||
      values of the referenced table and referenced columns using the
 | 
			
		||||
      given match type.  There are three match types: <literal>MATCH
 | 
			
		||||
      FULL</>, <literal>MATCH PARTIAL</>, and <literal>MATCH
 | 
			
		||||
      SIMPLE</literal>, which is also the default.  <literal>MATCH
 | 
			
		||||
      FULL</> will not allow one column of a multicolumn foreign key
 | 
			
		||||
      to be null unless all foreign key columns are null.
 | 
			
		||||
      <literal>MATCH SIMPLE</literal> allows some foreign key columns
 | 
			
		||||
      to be null while other parts of the foreign key are not
 | 
			
		||||
      null. <literal>MATCH PARTIAL</> is not yet implemented.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      In addition, when the data in the referenced columns is changed,
 | 
			
		||||
      certain actions are performed on the data in this table's
 | 
			
		||||
      columns.  The <literal>ON DELETE</literal> clause specifies the
 | 
			
		||||
      action to do when a referenced row in the referenced table is
 | 
			
		||||
      action to perform when a referenced row in the referenced table is
 | 
			
		||||
      being deleted.  Likewise, the <literal>ON UPDATE</literal>
 | 
			
		||||
      clause specifies the action to perform when a referenced column
 | 
			
		||||
      in the referenced table is being updated to a new value. If the
 | 
			
		||||
@ -434,7 +431,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
        <term><literal>SET NULL</literal></term>
 | 
			
		||||
        <listitem>
 | 
			
		||||
         <para>
 | 
			
		||||
          Set the referencing column values to NULL.
 | 
			
		||||
          Set the referencing column values to null.
 | 
			
		||||
         </para>
 | 
			
		||||
        </listitem>
 | 
			
		||||
       </varlistentry>
 | 
			
		||||
@ -449,19 +446,20 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
       </varlistentry>
 | 
			
		||||
      </variablelist>
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      If primary key column is updated frequently, it may be wise to
 | 
			
		||||
      add an index to the <literal>REFERENCES</literal> column so that
 | 
			
		||||
      <literal>NO ACTION</literal> and <literal>CASCADE</literal>
 | 
			
		||||
      actions associated with the <literal>REFERENCES</literal>
 | 
			
		||||
      column can be more efficiently performed.
 | 
			
		||||
      add an index to the foreign key column so that <literal>NO
 | 
			
		||||
      ACTION</literal> and <literal>CASCADE</literal> actions
 | 
			
		||||
      associated with the foreign key column can be more efficiently
 | 
			
		||||
      performed.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
   
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>DEFERRABLE</literal> or <literal>NOT DEFERRABLE</literal></term>
 | 
			
		||||
    <term><literal>DEFERRABLE</literal></term>
 | 
			
		||||
    <term><literal>NOT DEFERRABLE</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      This controls whether the constraint can be deferred.  A
 | 
			
		||||
@ -477,7 +475,8 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>INITIALLY IMMEDIATE</literal> or <literal>INITIALLY DEFERRED</literal></term>
 | 
			
		||||
    <term><literal>INITIALLY IMMEDIATE</literal></term>
 | 
			
		||||
    <term><literal>INITIALLY DEFERRED</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      If a constraint is deferrable, this clause specifies the default
 | 
			
		||||
@ -541,45 +540,16 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
 <refsect1 id="SQL-CREATETABLE-diagnostics">
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <msgset>
 | 
			
		||||
   <msgentry>
 | 
			
		||||
    <msg>
 | 
			
		||||
     <msgmain>
 | 
			
		||||
      <msgtext>
 | 
			
		||||
       <simpara><computeroutput>CREATE TABLE</computeroutput></simpara>
 | 
			
		||||
      </msgtext>
 | 
			
		||||
     </msgmain>
 | 
			
		||||
    </msg>
 | 
			
		||||
 | 
			
		||||
    <msgexplan>
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE TABLE</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if table is successfully created.
 | 
			
		||||
      Message returned if the table was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </msgexplan>
 | 
			
		||||
   </msgentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
   <msgentry>
 | 
			
		||||
    <msg>
 | 
			
		||||
     <msgmain>
 | 
			
		||||
      <msgtext>
 | 
			
		||||
       <simpara><computeroutput>ERROR</computeroutput></simpara>
 | 
			
		||||
      </msgtext>
 | 
			
		||||
     </msgmain>
 | 
			
		||||
    </msg>
 | 
			
		||||
 | 
			
		||||
    <msgexplan>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if table creation failed.  This is usually
 | 
			
		||||
      accompanied by some descriptive text, such as:
 | 
			
		||||
      <computeroutput>ERROR: Relation '<replaceable
 | 
			
		||||
      class="parameter">table</replaceable>' already
 | 
			
		||||
      exists</computeroutput>, which occurs at run time if the table
 | 
			
		||||
      specified already exists in the database.
 | 
			
		||||
     </para>
 | 
			
		||||
    </msgexplan>
 | 
			
		||||
   </msgentry>
 | 
			
		||||
  </msgset>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -622,17 +592,6 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
    </para>
 | 
			
		||||
   </listitem>
 | 
			
		||||
 | 
			
		||||
   <listitem>
 | 
			
		||||
    <para>
 | 
			
		||||
     The SQL92 standard says that <literal>CHECK</> column constraints
 | 
			
		||||
     may only refer to the column they apply to; only
 | 
			
		||||
     <literal>CHECK</> table constraints may refer to multiple
 | 
			
		||||
     columns.  <productname>PostgreSQL</productname> does not enforce
 | 
			
		||||
     this restriction; it treats column and table check constraints
 | 
			
		||||
     alike.
 | 
			
		||||
    </para>
 | 
			
		||||
   </listitem>
 | 
			
		||||
 | 
			
		||||
   <listitem>
 | 
			
		||||
    <para>
 | 
			
		||||
     Unique constraints and primary keys are not inherited in the
 | 
			
		||||
@ -653,19 +612,19 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE films (
 | 
			
		||||
    code        CHARACTER(5) CONSTRAINT firstkey PRIMARY KEY,
 | 
			
		||||
    title       CHARACTER VARYING(40) NOT NULL,
 | 
			
		||||
    did         DECIMAL(3) NOT NULL,
 | 
			
		||||
    date_prod   DATE,
 | 
			
		||||
    kind        CHAR(10),
 | 
			
		||||
    len         INTERVAL HOUR TO MINUTE
 | 
			
		||||
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
 | 
			
		||||
    title       varchar(40) NOT NULL,
 | 
			
		||||
    did         integer NOT NULL,
 | 
			
		||||
    date_prod   date,
 | 
			
		||||
    kind        varchar(10),
 | 
			
		||||
    len         interval hour to minute
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
     did    DECIMAL(3) PRIMARY KEY DEFAULT NEXTVAL('serial'),
 | 
			
		||||
     name   VARCHAR(40) NOT NULL CHECK (name <> '')
 | 
			
		||||
     did    integer PRIMARY KEY DEFAULT nextval('serial'),
 | 
			
		||||
     name   varchar(40) NOT NULL CHECK (name <> '')
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
@ -675,23 +634,24 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE array (
 | 
			
		||||
    vector  INT[][]
 | 
			
		||||
    vector  int[][]
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Define a unique table constraint for the table films.  Unique table
 | 
			
		||||
   constraints can be defined on one or more columns of the table:
 | 
			
		||||
   Define a unique table constraint for the table
 | 
			
		||||
   <literal>films</literal>.  Unique table constraints can be defined
 | 
			
		||||
   on one or more columns of the table.
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE films (
 | 
			
		||||
    code        CHAR(5),
 | 
			
		||||
    title       VARCHAR(40),
 | 
			
		||||
    did         DECIMAL(3),
 | 
			
		||||
    date_prod   DATE,
 | 
			
		||||
    kind        VARCHAR(10),
 | 
			
		||||
    len         INTERVAL HOUR TO MINUTE,
 | 
			
		||||
    code        char(5),
 | 
			
		||||
    title       varchar(40),
 | 
			
		||||
    did         integer,
 | 
			
		||||
    date_prod   date,
 | 
			
		||||
    kind        varchar(10),
 | 
			
		||||
    len         interval hour to minute,
 | 
			
		||||
    CONSTRAINT production UNIQUE(date_prod)
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
@ -702,8 +662,8 @@ CREATE TABLE films (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3) CHECK (did > 100),
 | 
			
		||||
    name    VARCHAR(40)
 | 
			
		||||
    did     integer CHECK (did > 100),
 | 
			
		||||
    name    varchar(40)
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
@ -713,8 +673,8 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3),
 | 
			
		||||
    name    VARCHAR(40)
 | 
			
		||||
    did     integer,
 | 
			
		||||
    name    varchar(40)
 | 
			
		||||
    CONSTRAINT con1 CHECK (did > 100 AND name <> '')
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
@ -727,12 +687,12 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE films (
 | 
			
		||||
    code        CHAR(5),
 | 
			
		||||
    title       VARCHAR(40),
 | 
			
		||||
    did         DECIMAL(3),
 | 
			
		||||
    date_prod   DATE,
 | 
			
		||||
    kind        VARCHAR(10),
 | 
			
		||||
    len         INTERVAL HOUR TO MINUTE,
 | 
			
		||||
    code        char(5),
 | 
			
		||||
    title       varchar(40),
 | 
			
		||||
    did         integer,
 | 
			
		||||
    date_prod   date,
 | 
			
		||||
    kind        varchar(10),
 | 
			
		||||
    len         interval hour to minute,
 | 
			
		||||
    CONSTRAINT code_title PRIMARY KEY(code,title)
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
@ -746,33 +706,33 @@ CREATE TABLE films (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3),
 | 
			
		||||
    name    CHAR VARYING(40),
 | 
			
		||||
    did     integer,
 | 
			
		||||
    name    varchar(40),
 | 
			
		||||
    PRIMARY KEY(did)
 | 
			
		||||
); 
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3) PRIMARY KEY,
 | 
			
		||||
    name    VARCHAR(40)
 | 
			
		||||
    did     integer PRIMARY KEY,
 | 
			
		||||
    name    varchar(40)
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   This assigns a literal constant default value for the column
 | 
			
		||||
   <literal>name</literal>, and arranges for the default value of
 | 
			
		||||
   column <literal>did</literal> to be generated by selecting the next
 | 
			
		||||
   value of a sequence object.  The default value of
 | 
			
		||||
   <literal>modtime</literal> will be the time at which the row is
 | 
			
		||||
   <literal>name</literal>, arranges for the default value of column
 | 
			
		||||
   <literal>did</literal> to be generated by selecting the next value
 | 
			
		||||
   of a sequence object, and makes the default value of
 | 
			
		||||
   <literal>modtime</literal> be the time at which the row is
 | 
			
		||||
   inserted.
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    name      VARCHAR(40) DEFAULT 'luso films',
 | 
			
		||||
    did       INTEGER DEFAULT NEXTVAL('distributors_serial'),
 | 
			
		||||
    modtime   TIMESTAMP DEFAULT CURRENT_TIMESTAMP
 | 
			
		||||
    name      varchar(40) DEFAULT 'Luso Films',
 | 
			
		||||
    did       integer DEFAULT nextval('distributors_serial'),
 | 
			
		||||
    modtime   timestamp DEFAULT current_timestamp
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
@ -784,8 +744,8 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3) CONSTRAINT no_null NOT NULL,
 | 
			
		||||
    name    VARCHAR(40) NOT NULL
 | 
			
		||||
    did     integer CONSTRAINT no_null NOT NULL,
 | 
			
		||||
    name    varchar(40) NOT NULL
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
    </para>
 | 
			
		||||
@ -795,8 +755,8 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3),
 | 
			
		||||
    name    VARCHAR(40) UNIQUE
 | 
			
		||||
    did     integer,
 | 
			
		||||
    name    varchar(40) UNIQUE
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
 | 
			
		||||
@ -804,8 +764,8 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did     DECIMAL(3),
 | 
			
		||||
    name    VARCHAR(40),
 | 
			
		||||
    did     integer,
 | 
			
		||||
    name    varchar(40),
 | 
			
		||||
    UNIQUE(name)
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
@ -818,8 +778,7 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <command>CREATE TABLE</command> command conforms to SQL92
 | 
			
		||||
   and to a subset of SQL99, with exceptions listed below and in the
 | 
			
		||||
   descriptions above.
 | 
			
		||||
   and to a subset of SQL99, with exceptions listed below.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <refsect2>
 | 
			
		||||
@ -827,27 +786,25 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Although the syntax of <literal>CREATE TEMPORARY TABLE</literal>
 | 
			
		||||
    resembles that of SQL92, the effect is not the same.  In the standard,
 | 
			
		||||
    resembles that of SQL standard, the effect is not the same.  In the standard,
 | 
			
		||||
    temporary tables are defined just once and automatically exist (starting
 | 
			
		||||
    with empty contents) in every session that needs them.
 | 
			
		||||
    <productname>PostgreSQL</productname> instead
 | 
			
		||||
    requires each session to issue its own <literal>CREATE TEMPORARY
 | 
			
		||||
    TABLE</literal> command for each temporary table to be used.  This allows
 | 
			
		||||
    different sessions to use the same temporary table name for different
 | 
			
		||||
    purposes, whereas the spec's approach constrains all instances of a
 | 
			
		||||
    purposes, whereas the standard's approach constrains all instances of a
 | 
			
		||||
    given temporary table name to have the same table structure.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <note>
 | 
			
		||||
    <para>
 | 
			
		||||
     The spec-mandated behavior of temporary tables is widely ignored.
 | 
			
		||||
     <productname>PostgreSQL</productname>'s behavior on this point is similar
 | 
			
		||||
     to that of several other RDBMSs.
 | 
			
		||||
    </para>
 | 
			
		||||
   </note>
 | 
			
		||||
   <para>
 | 
			
		||||
    The behavior of temporary tables mandated by the standard is
 | 
			
		||||
    widely ignored.  <productname>PostgreSQL</productname>'s behavior
 | 
			
		||||
    on this point is similar to that of several other SQL databases.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    SQL92's distinction between global and local temporary tables
 | 
			
		||||
    The standard's distinction between global and local temporary tables
 | 
			
		||||
    is not in <productname>PostgreSQL</productname>, since that distinction
 | 
			
		||||
    depends on the concept of modules, which
 | 
			
		||||
    <productname>PostgreSQL</productname> does not have.
 | 
			
		||||
@ -855,12 +812,24 @@ CREATE TABLE distributors (
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The <literal>ON COMMIT</literal> clause for temporary tables
 | 
			
		||||
    also resembles SQL92, but has some differences.
 | 
			
		||||
    If the <literal>ON COMMIT</> clause is omitted, SQL92 specifies that the
 | 
			
		||||
    also resembles the SQL standard, but has some differences.
 | 
			
		||||
    If the <literal>ON COMMIT</> clause is omitted, SQL specifies that the
 | 
			
		||||
    default behavior is <literal>ON COMMIT DELETE ROWS</>.  However, the
 | 
			
		||||
    default behavior in <productname>PostgreSQL</productname> is
 | 
			
		||||
    <literal>ON COMMIT PRESERVE ROWS</literal>.  The <literal>ON COMMIT
 | 
			
		||||
    DROP</literal> option does not exist in SQL92.
 | 
			
		||||
    DROP</literal> option does not exist in SQL.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2>
 | 
			
		||||
   <title>Column Check Constraints</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The SQL standard says that <literal>CHECK</> column constraints
 | 
			
		||||
    may only refer to the column they apply to; only <literal>CHECK</>
 | 
			
		||||
    table constraints may refer to multiple columns.
 | 
			
		||||
    <productname>PostgreSQL</productname> does not enforce this
 | 
			
		||||
    restriction; it treats column and table check constraints alike.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
@ -870,49 +839,13 @@ CREATE TABLE distributors (
 | 
			
		||||
   <para>
 | 
			
		||||
    The <literal>NULL</> <quote>constraint</quote> (actually a
 | 
			
		||||
    non-constraint) is a <productname>PostgreSQL</productname>
 | 
			
		||||
    extension to SQL92 that is included for compatibility with some
 | 
			
		||||
    other RDBMSs (and for symmetry with the <literal>NOT
 | 
			
		||||
    extension to the SQL standard that is included for compatibility with some
 | 
			
		||||
    other database systems (and for symmetry with the <literal>NOT
 | 
			
		||||
    NULL</literal> constraint).  Since it is the default for any
 | 
			
		||||
    column, its presence is simply noise.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
   
 | 
			
		||||
  <refsect2>
 | 
			
		||||
   <title>Assertions</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    An assertion is a special type of integrity constraint and shares
 | 
			
		||||
    the same namespace as other constraints. However, an assertion is
 | 
			
		||||
    not necessarily dependent on one particular table as constraints
 | 
			
		||||
    are, so SQL92 provides the <command>CREATE ASSERTION</command>
 | 
			
		||||
    statement as an alternate method for defining a constraint:
 | 
			
		||||
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE ASSERTION <replaceable>name</replaceable> CHECK ( <replaceable>condition</replaceable> )
 | 
			
		||||
</synopsis>
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <productname>PostgreSQL</> does not implement assertions at present.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
<!--    
 | 
			
		||||
    <para>
 | 
			
		||||
     Domain constraints are defined by <command>CREATE
 | 
			
		||||
     DOMAIN</command> or <command>ALTER DOMAIN</command> statements:
 | 
			
		||||
    </para>
 | 
			
		||||
    <para>
 | 
			
		||||
     Domain constraint: 
 | 
			
		||||
 | 
			
		||||
     <synopsis>
 | 
			
		||||
[ CONSTRAINT <replaceable>constraint_name</replaceable> ] CHECK <replaceable>constraint</replaceable> 
 | 
			
		||||
    [ {INITIALLY DEFERRED | INITIALLY IMMEDIATE} ]
 | 
			
		||||
    [ [ NOT ] DEFERRABLE ]
 | 
			
		||||
     </synopsis>
 | 
			
		||||
    </para>
 | 
			
		||||
-->
 | 
			
		||||
   
 | 
			
		||||
  <refsect2>
 | 
			
		||||
   <title>Inheritance</title>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.11 2002/11/21 23:34:43 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.12 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -18,16 +18,12 @@ PostgreSQL documentation
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ]
 | 
			
		||||
    AS <replaceable>query</replaceable>
 | 
			
		||||
  </synopsis>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2001-03-20</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE TABLE AS</command> creates a table and fills it
 | 
			
		||||
   with data computed by a <command>SELECT</command> command.  The
 | 
			
		||||
@ -75,10 +71,9 @@ CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name</replace
 | 
			
		||||
    <term><replaceable>column_name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of a column in the new table. Multiple column names can
 | 
			
		||||
      be specified using a comma-delimited list of column names.  If
 | 
			
		||||
      column names are not provided, they are taken from the output
 | 
			
		||||
      column names of the query.
 | 
			
		||||
      The name of a column in the new table.  If column names are not
 | 
			
		||||
      provided, they are taken from the output column names of the
 | 
			
		||||
      query.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
@ -124,21 +119,12 @@ CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name</replace
 | 
			
		||||
  <para>
 | 
			
		||||
   This command is modeled after an <productname>Oracle</productname>
 | 
			
		||||
   feature.  There is no command with equivalent functionality in
 | 
			
		||||
   SQL92 or SQL99.  However, a combination of <literal>CREATE
 | 
			
		||||
   the SQL standard.  However, a combination of <literal>CREATE
 | 
			
		||||
   TABLE</literal> and <literal>INSERT ... SELECT</literal> can
 | 
			
		||||
   accomplish the same thing with little more effort.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>History</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <command>CREATE TABLE AS</command> command has been available
 | 
			
		||||
   since <productname>PostgreSQL</productname> 6.3.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>See Also</title>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.33 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.34 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,186 +8,57 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="SQL-CREATETRIGGER-TITLE">CREATE TRIGGER</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE TRIGGER
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new trigger
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE TRIGGER</refname>
 | 
			
		||||
  <refpurpose>define a new trigger</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2000-03-25</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
<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 } ]
 | 
			
		||||
    EXECUTE PROCEDURE <replaceable class="PARAMETER">func</replaceable> ( <replaceable class="PARAMETER">arguments</replaceable> )
 | 
			
		||||
  </synopsis>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATETRIGGER-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-21</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name to give the new trigger.  This must be distinct from the name
 | 
			
		||||
	of any other trigger for the same table.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>BEFORE</term>
 | 
			
		||||
      <term>AFTER</term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
		Determines whether the function is called before or after the
 | 
			
		||||
		event.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">event</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
		One of <command>INSERT</command>, <command>DELETE</command> or
 | 
			
		||||
		<command>UPDATE</command>; this specifies the event that will
 | 
			
		||||
		fire the trigger. Multiple events can be specified using
 | 
			
		||||
		<literal>OR</literal>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">table</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
		The name (optionally schema-qualified) of the table the
 | 
			
		||||
		trigger is for.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
	 <varlistentry>
 | 
			
		||||
	  <term>FOR EACH ROW</term>
 | 
			
		||||
	  <term>FOR EACH STATEMENT</term>
 | 
			
		||||
 | 
			
		||||
	  <listitem>
 | 
			
		||||
	   <para>
 | 
			
		||||
		This specifies whether the trigger procedure should be fired
 | 
			
		||||
		once for every row affected by the trigger event, or just once
 | 
			
		||||
		per SQL statement. If neither is specified, <literal>FOR EACH
 | 
			
		||||
		STATEMENT</literal> is the default.
 | 
			
		||||
	   </para>
 | 
			
		||||
	  </listitem>
 | 
			
		||||
	 </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">func</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	A user-supplied function that is declared as taking no arguments
 | 
			
		||||
	and returning type <literal>trigger</>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">arguments</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
    An optional comma-separated list of arguments to be provided to
 | 
			
		||||
	the function when the trigger is executed, along with the standard
 | 
			
		||||
	trigger data such as old and new tuple contents.  The arguments
 | 
			
		||||
	are literal string constants.  Simple names and numeric constants
 | 
			
		||||
	may be written here too, but they will all be converted to
 | 
			
		||||
	strings. Note that these arguments are not provided as normal
 | 
			
		||||
	function parameters (since a trigger procedure must be declared to
 | 
			
		||||
	take zero parameters), but are instead accessed through the
 | 
			
		||||
	<literal>TG_ARGV</literal> array.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATETRIGGER-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-21</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE TRIGGER
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	This message is returned if the trigger is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATETRIGGER-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>1998-09-21</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE TRIGGER</command> will enter a new trigger into the current
 | 
			
		||||
   database.  The trigger will be associated with the relation
 | 
			
		||||
   <replaceable class="parameter">table</replaceable> and will execute
 | 
			
		||||
   the specified function <replaceable class="parameter">func</replaceable>.
 | 
			
		||||
   <command>CREATE TRIGGER</command> creates a new trigger.  The
 | 
			
		||||
   trigger will be associated with the specified table and will
 | 
			
		||||
   execute the specified function <replaceable
 | 
			
		||||
   class="parameter">func</replaceable> when certain events occur.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The trigger can be specified to fire either before BEFORE the
 | 
			
		||||
   operation is attempted on a tuple (before constraints are checked and
 | 
			
		||||
   the <command>INSERT</command>, <command>UPDATE</command> or
 | 
			
		||||
   <command>DELETE</command> is attempted) or AFTER the operation has
 | 
			
		||||
   been attempted (e.g., after constraints are checked and the
 | 
			
		||||
   <command>INSERT</command>, <command>UPDATE</command> or
 | 
			
		||||
   <command>DELETE</command> has completed). If the trigger fires before
 | 
			
		||||
   the event, the trigger may skip the operation for the current tuple,
 | 
			
		||||
   or change the tuple being inserted (for <command>INSERT</command> and
 | 
			
		||||
   <command>UPDATE</command> operations only). If the trigger fires
 | 
			
		||||
   after the event, all changes, including the last insertion, update,
 | 
			
		||||
   or deletion, are <quote>visible</quote> to the trigger.
 | 
			
		||||
   The trigger can be specified to fire either before before the
 | 
			
		||||
   operation is attempted on a row (before constraints are checked and
 | 
			
		||||
   the <command>INSERT</command>, <command>UPDATE</command>, or
 | 
			
		||||
   <command>DELETE</command> is attempted) or after the operation has
 | 
			
		||||
   completed (after constraints are checked and the
 | 
			
		||||
   <command>INSERT</command>, <command>UPDATE</command>, or
 | 
			
		||||
   <command>DELETE</command> has completed). If the trigger fires
 | 
			
		||||
   before the event, the trigger may skip the operation for the
 | 
			
		||||
   current row, or change the row being inserted (for
 | 
			
		||||
   <command>INSERT</command> and <command>UPDATE</command> operations
 | 
			
		||||
   only). If the trigger fires after the event, all changes, including
 | 
			
		||||
   the last insertion, update, or deletion, are <quote>visible</quote>
 | 
			
		||||
   to the trigger.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   A trigger that executes <literal>FOR EACH ROW</literal> of the
 | 
			
		||||
   specified operation is called once for every row that the operation
 | 
			
		||||
   modifies. For example, a <command>DELETE</command> that affects 10
 | 
			
		||||
   rows will cause any <literal>ON DELETE</literal> triggers on the
 | 
			
		||||
   target relation to be called 10 separate times, once for each
 | 
			
		||||
   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 (in particular, an operation that modifies zero rows will
 | 
			
		||||
   still result in the execution of any applicable <literal>FOR EACH
 | 
			
		||||
   STATEMENT</literal> triggers).
 | 
			
		||||
   A trigger that is marked <literal>FOR EACH ROW</literal> is called
 | 
			
		||||
   once for every row that the operation modifies. For example, a
 | 
			
		||||
   <command>DELETE</command> that affects 10 rows will cause any
 | 
			
		||||
   <literal>ON DELETE</literal> triggers on the target relation to be
 | 
			
		||||
   called 10 separate times, once for each deleted row. In contrast, a
 | 
			
		||||
   trigger that is marked <literal>FOR EACH STATEMENT</literal> only
 | 
			
		||||
   executes once for any given operation, regardless of how many rows
 | 
			
		||||
   it 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>
 | 
			
		||||
@ -202,9 +73,114 @@ CREATE TRIGGER
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Refer to <xref linkend="server-programming"> for more information.
 | 
			
		||||
   Refer to <xref linkend="triggers"> for more information about triggers.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name to give the new trigger.  This must be distinct from
 | 
			
		||||
      the name of any other trigger for the same table.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>BEFORE</literal></term>
 | 
			
		||||
    <term><literal>AFTER</literal></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Determines whether the function is called before or after the
 | 
			
		||||
      event.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">event</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      One of <command>INSERT</command>, <command>UPDATE</command>, or
 | 
			
		||||
      <command>DELETE</command>; this specifies the event that will
 | 
			
		||||
      fire the trigger. Multiple events can be specified using
 | 
			
		||||
      <literal>OR</literal>.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">table</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of the table the trigger
 | 
			
		||||
      is for.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><literal>FOR EACH ROW</literal></term>
 | 
			
		||||
    <term><literal>FOR EACH STATEMENT</literal></term>
 | 
			
		||||
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      This specifies whether the trigger procedure should be fired
 | 
			
		||||
      once for every row affected by the trigger event, or just once
 | 
			
		||||
      per SQL statement. If neither is specified, <literal>FOR EACH
 | 
			
		||||
      STATEMENT</literal> is the default.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">func</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      A user-supplied function that is declared as taking no arguments
 | 
			
		||||
      and returning type <literal>trigger</>, which is executed when
 | 
			
		||||
      the trigger fires.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">arguments</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      An optional comma-separated list of arguments to be provided to
 | 
			
		||||
      the function when the trigger is executed.  The arguments are
 | 
			
		||||
      literal string constants.  Simple names and numeric constants
 | 
			
		||||
      may be written here, too, but they will all be converted to
 | 
			
		||||
      strings.  Please check the description of the implementation
 | 
			
		||||
      language of the trigger function about how the trigger arguments
 | 
			
		||||
      are accessible within the function; it may be different from
 | 
			
		||||
      normal function arguments.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE TRIGGER</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the trigger was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="SQL-CREATETRIGGER-notes">
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
@ -219,13 +195,13 @@ CREATE TRIGGER
 | 
			
		||||
   necessary to declare trigger functions as returning the placeholder
 | 
			
		||||
   type <type>opaque</>, rather than <type>trigger</>.  To support loading
 | 
			
		||||
   of old dump files, <command>CREATE TRIGGER</> will accept a function
 | 
			
		||||
   declared as returning <type>opaque</>, but it will issue a NOTICE and
 | 
			
		||||
   declared as returning <type>opaque</>, but it will issue a notice and
 | 
			
		||||
   change the function's declared return type to <type>trigger</>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Refer to the <xref linkend="sql-droptrigger" endterm="sql-droptrigger-title"> command for
 | 
			
		||||
   information on how to remove triggers.
 | 
			
		||||
   Use <xref linkend="sql-droptrigger"
 | 
			
		||||
   endterm="sql-droptrigger-title"> to remove a trigger.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
@ -233,111 +209,64 @@ CREATE TRIGGER
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Check if the specified distributor code exists in the distributors
 | 
			
		||||
   table before appending or updating a row in the table films:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TRIGGER if_dist_exists
 | 
			
		||||
    BEFORE INSERT OR UPDATE ON films FOR EACH ROW
 | 
			
		||||
    EXECUTE PROCEDURE check_primary_key ('did', 'distributors', 'did');
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Before cancelling a distributor or updating its code, remove every
 | 
			
		||||
   reference to the table films:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TRIGGER if_film_exists 
 | 
			
		||||
    BEFORE DELETE OR UPDATE ON distributors FOR EACH ROW
 | 
			
		||||
    EXECUTE PROCEDURE check_foreign_key (1, 'CASCADE', 'did', 'films', 'did');
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The second example can also be done by using a foreign key,
 | 
			
		||||
   constraint as in:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TABLE distributors (
 | 
			
		||||
    did      DECIMAL(3),
 | 
			
		||||
    name     VARCHAR(40),
 | 
			
		||||
    CONSTRAINT if_film_exists
 | 
			
		||||
    FOREIGN KEY(did) REFERENCES films
 | 
			
		||||
    ON UPDATE CASCADE ON DELETE CASCADE  
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
   <xref linkend="trigger-example"> contains a complete example.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="SQL-CREATETRIGGER-compatibility">
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
  
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term>SQL92</term>
 | 
			
		||||
  <para>
 | 
			
		||||
   The <command>CREATE TRIGGER</command> statement in
 | 
			
		||||
   <productname>PostgreSQL</productname> implements a subset of the
 | 
			
		||||
   SQL99 standard.  (There are no provisions for triggers in SQL92.)
 | 
			
		||||
   The following functionality is missing:
 | 
			
		||||
 | 
			
		||||
   <itemizedlist>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      There is no <command>CREATE TRIGGER</command> statement in <acronym>SQL92</acronym>.
 | 
			
		||||
      SQL99 allows triggers to fire on updates to specific columns
 | 
			
		||||
      (e.g., <literal>AFTER UPDATE OF col1, col2</literal>).
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term>SQL99</term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The <command>CREATE TRIGGER</command> statement in
 | 
			
		||||
      <productname>PostgreSQL</productname> implements a subset of the
 | 
			
		||||
      SQL99 standard.  The following functionality is missing:
 | 
			
		||||
      <itemizedlist>
 | 
			
		||||
       <listitem>
 | 
			
		||||
        <para>
 | 
			
		||||
         SQL99 allows triggers to fire on updates to specific columns
 | 
			
		||||
         (e.g., <literal>AFTER UPDATE OF col1, col2</literal>).
 | 
			
		||||
        </para>
 | 
			
		||||
       </listitem>
 | 
			
		||||
 | 
			
		||||
       <listitem>
 | 
			
		||||
        <para>
 | 
			
		||||
         SQL99 allows you to define aliases for the <quote>old</quote>
 | 
			
		||||
         and <quote>new</quote> rows or tables for use in the definition
 | 
			
		||||
         of the triggered action (e.g., <literal>CREATE TRIGGER ... ON
 | 
			
		||||
         tablename REFERENCING OLD ROW AS somename NEW ROW AS
 | 
			
		||||
         othername ...</literal>).  Since
 | 
			
		||||
         <productname>PostgreSQL</productname> allows trigger
 | 
			
		||||
         procedures to be written in any number of user-defined
 | 
			
		||||
         languages, access to the data is handled in a
 | 
			
		||||
         language-specific way.
 | 
			
		||||
        </para>
 | 
			
		||||
       </listitem>
 | 
			
		||||
 | 
			
		||||
       <listitem>
 | 
			
		||||
        <para>
 | 
			
		||||
         <productname>PostgreSQL</productname> only allows the
 | 
			
		||||
         execution of a stored procedure for the triggered action.
 | 
			
		||||
         SQL99 allows the execution of a number of other SQL commands,
 | 
			
		||||
         such as <command>CREATE TABLE</command> as triggered action.
 | 
			
		||||
         This limitation is not hard to work around by creating a
 | 
			
		||||
         stored procedure that executes these commands.
 | 
			
		||||
        </para>
 | 
			
		||||
       </listitem>
 | 
			
		||||
      </itemizedlist>
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      SQL99 specifies that multiple triggers should be fired in
 | 
			
		||||
      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.
 | 
			
		||||
      SQL99 allows you to define aliases for the <quote>old</quote>
 | 
			
		||||
      and <quote>new</quote> rows or tables for use in the definition
 | 
			
		||||
      of the triggered action (e.g., <literal>CREATE TRIGGER ... ON
 | 
			
		||||
      tablename REFERENCING OLD ROW AS somename NEW ROW AS othername
 | 
			
		||||
      ...</literal>).  Since <productname>PostgreSQL</productname>
 | 
			
		||||
      allows trigger procedures to be written in any number of
 | 
			
		||||
      user-defined languages, access to the data is handled in a
 | 
			
		||||
      language-specific way.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      <productname>PostgreSQL</productname> only allows the execution
 | 
			
		||||
      of a user-defined function for the triggered action.  SQL99
 | 
			
		||||
      allows the execution of a number of other SQL commands, such as
 | 
			
		||||
      <command>CREATE TABLE</command> as triggered action.  This
 | 
			
		||||
      limitation is not hard to work around by creating a user-defined
 | 
			
		||||
      function that executes the desired commands.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </itemizedlist>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   SQL99 specifies that multiple triggers should be fired in
 | 
			
		||||
   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>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.40 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.41 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,22 +8,17 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="sql-createtype-title">CREATE TYPE</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE TYPE
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new data type
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE TYPE</refname>
 | 
			
		||||
  <refpurpose>define a new data type</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>1999-07-20</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
CREATE TYPE <replaceable class="parameter">typename</replaceable> ( INPUT = <replaceable class="parameter">input_function</replaceable>, OUTPUT = <replaceable class="parameter">output_function</replaceable>
 | 
			
		||||
      , INTERNALLENGTH = { <replaceable
 | 
			
		||||
      class="parameter">internallength</replaceable> | VARIABLE }
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE TYPE <replaceable class="parameter">typename</replaceable> (
 | 
			
		||||
    INPUT = <replaceable class="parameter">input_function</replaceable>, OUTPUT = <replaceable class="parameter">output_function</replaceable>
 | 
			
		||||
      , INTERNALLENGTH = { <replaceable class="parameter">internallength</replaceable> | VARIABLE }
 | 
			
		||||
    [ , DEFAULT = <replaceable class="parameter">default</replaceable> ]
 | 
			
		||||
    [ , ELEMENT = <replaceable class="parameter">element</replaceable> ] [ , DELIMITER = <replaceable class="parameter">delimiter</replaceable> ]
 | 
			
		||||
    [ , PASSEDBYVALUE ]
 | 
			
		||||
@ -32,184 +27,26 @@ CREATE TYPE <replaceable class="parameter">typename</replaceable> ( INPUT = <rep
 | 
			
		||||
)
 | 
			
		||||
 | 
			
		||||
CREATE TYPE <replaceable class="parameter">typename</replaceable> AS
 | 
			
		||||
    ( <replaceable class="PARAMETER">column_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [, ... ] )
 | 
			
		||||
  </synopsis>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATETYPE-1">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-21</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">typename</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name (optionally schema-qualified) of a type to be created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">internallength</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	A literal value, which specifies the internal length of
 | 
			
		||||
	the new type.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">input_function</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of a function, created by
 | 
			
		||||
	<command>CREATE FUNCTION</command>, which
 | 
			
		||||
	converts data from its external form to the type's
 | 
			
		||||
	internal form.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">output_function</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name of a function, created by
 | 
			
		||||
	<command>CREATE FUNCTION</command>, which
 | 
			
		||||
	converts data from its internal form to a form suitable
 | 
			
		||||
	for display.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">element</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The type being created is an array; this specifies
 | 
			
		||||
	the type of the array elements.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">delimiter</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The delimiter character to be used between values in arrays made
 | 
			
		||||
	of this type.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">default</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The default value for the data type.  Usually this is omitted,
 | 
			
		||||
	so that the default is NULL.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">alignment</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Storage alignment requirement of the data type.  If specified, must
 | 
			
		||||
	be <literal>char</literal>, <literal>int2</literal>,
 | 
			
		||||
	<literal>int4</literal>, or <literal>double</literal>;
 | 
			
		||||
	the default is <literal>int4</literal>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">storage</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Storage technique for the data type.  If specified, must
 | 
			
		||||
	be <literal>plain</literal>, <literal>external</literal>,
 | 
			
		||||
	<literal>extended</literal>, or <literal>main</literal>;
 | 
			
		||||
	the default is <literal>plain</literal>.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">column_name</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The name of a column of the composite type.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="PARAMETER">data_type</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        The name of an existing data type.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATETYPE-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>1998-09-21</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE TYPE
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Message returned if the type is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
    ( <replaceable class="PARAMETER">attribute_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [, ... ] )
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATETYPE-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>1998-09-21</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE TYPE</command>  allows  the user to register a new data
 | 
			
		||||
   type with <productname>PostgreSQL</> for use in the current data base.
 | 
			
		||||
   The user  who  defines  a type becomes its owner.
 | 
			
		||||
   <command>CREATE TYPE</command> registers a new data type for use in
 | 
			
		||||
   the current data base.  The user who defines a type becomes its
 | 
			
		||||
   owner.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given then the type is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   The type name must be distinct from the name of any existing type or
 | 
			
		||||
   domain in the same schema.  (Because tables have associated data types,
 | 
			
		||||
   type names also must not conflict with table names in the same schema.)
 | 
			
		||||
   If a schema name is given then the type is created in the specified
 | 
			
		||||
   schema.  Otherwise it is created in the current schema.  The type
 | 
			
		||||
   name must be distinct from the name of any existing type or domain
 | 
			
		||||
   in the same schema.  (Because tables have associated data types,
 | 
			
		||||
   the type name must also be distinct from the name of any existing
 | 
			
		||||
   table in the same schema.)
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <refsect2>
 | 
			
		||||
@ -220,74 +57,59 @@ CREATE TYPE
 | 
			
		||||
   (scalar type).  It  requires  the
 | 
			
		||||
   registration of two functions (using <command>CREATE
 | 
			
		||||
   FUNCTION</command>) before defining the
 | 
			
		||||
   type. The representation of a new base type is determined by
 | 
			
		||||
   type. The internal representation of the new base type is determined by
 | 
			
		||||
   <replaceable class="parameter">input_function</replaceable>, which
 | 
			
		||||
   converts the type's external  representation  to  an  internal
 | 
			
		||||
   converts the type's external  representation to an internal
 | 
			
		||||
   representation  usable by the
 | 
			
		||||
   operators and functions defined for the type.   Naturally,
 | 
			
		||||
   operators and functions defined for the type.
 | 
			
		||||
   <replaceable class="parameter">output_function</replaceable>
 | 
			
		||||
   performs the reverse transformation.  The input function may be
 | 
			
		||||
   declared as taking one argument of type <type>cstring</type>,
 | 
			
		||||
   or as taking three arguments of types
 | 
			
		||||
   <type>cstring</type>, <type>OID</type>, <type>int4</type>.
 | 
			
		||||
   (The first argument is the input text as a C string, the second
 | 
			
		||||
   <type>cstring</type>, <type>oid</type>, <type>integer</type>.
 | 
			
		||||
   The first argument is the input text as a C string, the second
 | 
			
		||||
   argument is the element type in case this is an array type,
 | 
			
		||||
   and the third is the <literal>typmod</> of the destination column, if known.)
 | 
			
		||||
   and the third is the <literal>typmod</> of the destination column, if known.
 | 
			
		||||
   It should return a value of the data type itself.
 | 
			
		||||
   The output function may be
 | 
			
		||||
   declared as taking one argument of the new data type,  or as taking
 | 
			
		||||
   two arguments of which the second is type <type>OID</type>.
 | 
			
		||||
   (The second argument is again the array element type for array types.)
 | 
			
		||||
   two arguments of which the second is type <type>oid</type>.
 | 
			
		||||
   The second argument is again the array element type for array types.
 | 
			
		||||
   The output function should return type <type>cstring</type>.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   You should at this point be wondering how the input and output functions
 | 
			
		||||
   can be declared to have results or inputs of the new type, when they have
 | 
			
		||||
   can be declared to have results or arguments of the new type, when they have
 | 
			
		||||
   to be created before the new type can be created.  The answer is that the
 | 
			
		||||
   input function must be created first, then the output function, then the
 | 
			
		||||
   data type.
 | 
			
		||||
   <productname>PostgreSQL</productname> will first see the name of the new
 | 
			
		||||
   data type as the return type of the input function.  It will create a
 | 
			
		||||
   <quote>shell</> type, which is simply a placeholder entry in
 | 
			
		||||
   <literal>pg_type</>, and link the input function definition to the shell
 | 
			
		||||
   the system catalog, and link the input function definition to the shell
 | 
			
		||||
   type.  Similarly the output function will be linked to the (now already
 | 
			
		||||
   existing) shell type.  Finally, <command>CREATE TYPE</> replaces the
 | 
			
		||||
   shell entry with a complete type definition, and the new type can be used.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <note>
 | 
			
		||||
  <para>
 | 
			
		||||
   In <productname>PostgreSQL</productname> versions before 7.3, it was
 | 
			
		||||
   customary to avoid creating a shell type by replacing the functions'
 | 
			
		||||
   forward references to the type name with the placeholder pseudo-type
 | 
			
		||||
   <type>OPAQUE</>.  The <type>cstring</> inputs and
 | 
			
		||||
   results also had to be declared as <type>OPAQUE</> before 7.3.
 | 
			
		||||
   To support loading 
 | 
			
		||||
   of old dump files, <command>CREATE TYPE</> will accept functions
 | 
			
		||||
   declared using <type>opaque</>, but it will issue a NOTICE and
 | 
			
		||||
   change the function's declaration to use the correct types.
 | 
			
		||||
  </para>
 | 
			
		||||
  </note>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   New  base  data  types  can be fixed length, in which case
 | 
			
		||||
   Base data types can be fixed-length, in which case
 | 
			
		||||
   <replaceable class="parameter">internallength</replaceable> is a
 | 
			
		||||
   positive integer, or variable  length, indicated by setting
 | 
			
		||||
   <replaceable class="parameter">internallength</replaceable>
 | 
			
		||||
   to <option>VARIABLE</option>.  (Internally, this is represented
 | 
			
		||||
   to <literal>VARIABLE</literal>.  (Internally, this is represented
 | 
			
		||||
   by setting <literal>typlen</> to -1.)  The internal representation of all
 | 
			
		||||
   variable-length types must start with an integer giving the total
 | 
			
		||||
   variable-length types must start with a 4-byte integer giving the total
 | 
			
		||||
   length of this value of the type.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   To indicate that a type is an array,
 | 
			
		||||
   specify the type  of  the  array
 | 
			
		||||
   elements using the <option>ELEMENT</> keyword.  For example, to define
 | 
			
		||||
   an array of 4-byte integers ("int4"), specify
 | 
			
		||||
   <programlisting>ELEMENT = int4</programlisting>
 | 
			
		||||
   More details about array types appear below.
 | 
			
		||||
   To indicate that a type is an array, specify the type of the array
 | 
			
		||||
   elements using the <literal>ELEMENT</> key word.  For example, to
 | 
			
		||||
   define an array of 4-byte integers (<type>int4</type>), specify
 | 
			
		||||
   <literal>ELEMENT = int4</literal> More details about array types
 | 
			
		||||
   appear below.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
@ -295,29 +117,28 @@ CREATE TYPE
 | 
			
		||||
   representation of arrays of this type, <replaceable
 | 
			
		||||
   class="parameter">delimiter</replaceable> can be
 | 
			
		||||
   set to a specific character.  The default delimiter is the comma
 | 
			
		||||
   ('<literal>,</literal>').  Note that the delimiter is associated
 | 
			
		||||
   (<literal>,</literal>).  Note that the delimiter is associated
 | 
			
		||||
   with the array element type, not the array type itself.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   A default value may be specified, in case a user wants columns of the
 | 
			
		||||
   data type to default to something other than NULL.
 | 
			
		||||
   Specify the default with the <option>DEFAULT</option> keyword.
 | 
			
		||||
   (Such a default may be overridden by an explicit <option>DEFAULT</option>
 | 
			
		||||
   data type to default to something other than the null value.
 | 
			
		||||
   Specify the default with the <literal>DEFAULT</literal> key word.
 | 
			
		||||
   (Such a default may be overridden by an explicit <literal>DEFAULT</literal>
 | 
			
		||||
   clause attached to a particular column.)
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The  optional flag,  <option>PASSEDBYVALUE</option>, indicates that
 | 
			
		||||
   values of this data type are passed
 | 
			
		||||
   by  value  rather  than by reference.  Note that you
 | 
			
		||||
   may not pass by value types whose internal representation is 
 | 
			
		||||
   longer than the width of the <type>Datum</> type (four bytes on
 | 
			
		||||
   most machines, eight bytes on a few).
 | 
			
		||||
   The optional flag <literal>PASSEDBYVALUE</literal> indicates that
 | 
			
		||||
   values of this data type are passed by value rather than by
 | 
			
		||||
   reference.  You may not pass by value types whose internal
 | 
			
		||||
   representation is larger than the size of the <type>Datum</> type
 | 
			
		||||
   (4 bytes on most machines, 8 bytes on a few).
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <replaceable class="parameter">alignment</replaceable> keyword
 | 
			
		||||
   The <replaceable class="parameter">alignment</replaceable> parameter
 | 
			
		||||
   specifies the storage alignment required for the data type.  The
 | 
			
		||||
   allowed values equate to alignment on 1, 2, 4, or 8 byte boundaries.
 | 
			
		||||
   Note that variable-length types must have an alignment of at least
 | 
			
		||||
@ -325,21 +146,22 @@ CREATE TYPE
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   The <replaceable class="parameter">storage</replaceable> keyword
 | 
			
		||||
   allows selection of storage strategies for variable-length data types
 | 
			
		||||
   (only <literal>plain</literal> is allowed for fixed-length types).
 | 
			
		||||
   <literal>plain</literal> disables TOAST for the data type: it will always
 | 
			
		||||
   be stored in-line and not compressed.
 | 
			
		||||
   <literal>extended</literal> gives full TOAST capability: the system will
 | 
			
		||||
   first try to compress a long data value, and will move the value out of
 | 
			
		||||
   The <replaceable class="parameter">storage</replaceable> parameter
 | 
			
		||||
   allows selection of storage strategies for variable-length data
 | 
			
		||||
   types.  (Only <literal>plain</literal> is allowed for fixed-length
 | 
			
		||||
   types.)  <literal>plain</literal> specifies that data of the type
 | 
			
		||||
   will always be stored in-line and not compressed.
 | 
			
		||||
   <literal>extended</literal> specifies that the system will first
 | 
			
		||||
   try to compress a long data value, and will move the value out of
 | 
			
		||||
   the main table row if it's still too long.
 | 
			
		||||
   <literal>external</literal> allows the value to be moved out of the main
 | 
			
		||||
   table, but the system will not try to compress it.
 | 
			
		||||
   <literal>main</literal> allows compression, but discourages moving the
 | 
			
		||||
   value out of the main table.  (Data items with this storage method may
 | 
			
		||||
   still be moved out of the main table if there is no other way to make
 | 
			
		||||
   a row fit, but they will be kept in the main table preferentially over
 | 
			
		||||
   <literal>extended</literal> and <literal>external</literal> items.)
 | 
			
		||||
   <literal>external</literal> allows the value to be moved out of the
 | 
			
		||||
   main table, but the system will not try to compress it.
 | 
			
		||||
   <literal>main</literal> allows compression, but discourages moving
 | 
			
		||||
   the value out of the main table.  (Data items with this storage
 | 
			
		||||
   strategy may still be moved out of the main table if there is no
 | 
			
		||||
   other way to make a row fit, but they will be kept in the main
 | 
			
		||||
   table preferentially over <literal>extended</literal> and
 | 
			
		||||
   <literal>external</literal> items.)
 | 
			
		||||
  </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
@ -349,7 +171,7 @@ CREATE TYPE
 | 
			
		||||
  <para>
 | 
			
		||||
   The second form of <command>CREATE TYPE</command>
 | 
			
		||||
   creates a composite type.
 | 
			
		||||
   The composite type is specified by a list of column names and data types.
 | 
			
		||||
   The composite type is specified by a list of attribute names and data types.
 | 
			
		||||
   This is essentially the same as the row type
 | 
			
		||||
   of a table, but using <command>CREATE TYPE</command> avoids the need to
 | 
			
		||||
   create an actual table when all that is wanted is to define a type.
 | 
			
		||||
@ -373,19 +195,19 @@ CREATE TYPE
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    You might reasonably ask <quote>why is there an <option>ELEMENT</>
 | 
			
		||||
    option, if the system makes the correct array type automatically?</quote>
 | 
			
		||||
    You might reasonably ask why there is an <option>ELEMENT</>
 | 
			
		||||
    option, if the system makes the correct array type automatically.
 | 
			
		||||
    The only case where it's useful to use <option>ELEMENT</> is when you are
 | 
			
		||||
    making a fixed-length type that happens to be internally an array of N
 | 
			
		||||
    identical things, and you want to allow the N things to be accessed
 | 
			
		||||
    making a fixed-length type that happens to be internally an array of a number of
 | 
			
		||||
    identical things, and you want to allow these things to be accessed
 | 
			
		||||
    directly by subscripting, in addition to whatever operations you plan
 | 
			
		||||
    to provide for the type as a whole.  For example, type <type>name</>
 | 
			
		||||
    allows its constituent <type>char</>s to be accessed this way.
 | 
			
		||||
    A 2-D <type>point</> type could allow its two component floats to be
 | 
			
		||||
    allows its constituent <type>char</> elements to be accessed this way.
 | 
			
		||||
    A 2-D <type>point</> type could allow its two component numbers to be
 | 
			
		||||
    accessed like <literal>point[0]</> and <literal>point[1]</>.
 | 
			
		||||
    Note that
 | 
			
		||||
    this facility only works for fixed-length types whose internal form
 | 
			
		||||
    is exactly a sequence of N identical fixed-length fields.  A subscriptable
 | 
			
		||||
    is exactly a sequence of identical fixed-length fields.  A subscriptable
 | 
			
		||||
    variable-length type must have the generalized internal representation
 | 
			
		||||
    used by <literal>array_in</> and <literal>array_out</>.
 | 
			
		||||
    For historical reasons (i.e., this is clearly wrong but it's far too
 | 
			
		||||
@ -394,41 +216,196 @@ CREATE TYPE
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
  
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameter</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">typename</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of a type to be created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">internallength</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      A numeric constant that specifies the internal length of the new
 | 
			
		||||
      type.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">input_function</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of a function that converts data from the type's
 | 
			
		||||
      external form to the its internal form.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">output_function</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of a function that converts data from the type's
 | 
			
		||||
      internal form to a form suitable for display.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">element</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The type being created is an array; this specifies the type of
 | 
			
		||||
      the array elements.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">delimiter</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The delimiter character to be used between values in arrays made
 | 
			
		||||
      of this type.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">default</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The default value for the data type.  If this is omitted, the
 | 
			
		||||
      default is null.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">alignment</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The storage alignment requirement of the data type.  If specified,
 | 
			
		||||
      it must be <literal>char</literal>, <literal>int2</literal>,
 | 
			
		||||
      <literal>int4</literal>, or <literal>double</literal>; the
 | 
			
		||||
      default is <literal>int4</literal>.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">storage</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The storage strateg for the data type.  If specified, must be
 | 
			
		||||
      <literal>plain</literal>, <literal>external</literal>,
 | 
			
		||||
      <literal>extended</literal>, or <literal>main</literal>; the
 | 
			
		||||
      default is <literal>plain</literal>.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">attribute_name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of an attribute of the composite type.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">data_type</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name of an existing data type.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE TYPE</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the type was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="SQL-CREATETYPE-notes">
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    User-defined type names cannot begin with the underscore character
 | 
			
		||||
    (<quote><literal>_</literal></quote>) and can only be 62
 | 
			
		||||
    characters long (or in general <symbol>NAMEDATALEN</symbol> - 2, rather than
 | 
			
		||||
    the <symbol>NAMEDATALEN</symbol> - 1 characters allowed for other names).
 | 
			
		||||
    Type names beginning with underscore are
 | 
			
		||||
    reserved for internally-created array type names.
 | 
			
		||||
   </para>
 | 
			
		||||
  <para>
 | 
			
		||||
   User-defined type names cannot begin with the underscore character
 | 
			
		||||
   (<literal>_</literal>) and can only be 62 characters
 | 
			
		||||
   long (or in general <symbol>NAMEDATALEN</symbol> - 2, rather than
 | 
			
		||||
   the <symbol>NAMEDATALEN</symbol> - 1 characters allowed for other
 | 
			
		||||
   names).  Type names beginning with underscore are reserved for
 | 
			
		||||
   internally-created array type names.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   In <productname>PostgreSQL</productname> versions before 7.3, it
 | 
			
		||||
   was customary to avoid creating a shell type by replacing the
 | 
			
		||||
   functions' forward references to the type name with the placeholder
 | 
			
		||||
   pseudotype <type>opaque</>.  The <type>cstring</> arguments and
 | 
			
		||||
   results also had to be declared as <type>opaque</> before 7.3.  To
 | 
			
		||||
   support loading of old dump files, <command>CREATE TYPE</> will
 | 
			
		||||
   accept functions declared using <type>opaque</>, but it will issue
 | 
			
		||||
   a notice and change the function's declaration to use the correct
 | 
			
		||||
   types.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   This example creates the <type>box</type> data type and then uses the
 | 
			
		||||
   This example creates the data type <type>box</type> and then uses the
 | 
			
		||||
   type in a table definition:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TYPE box (INTERNALLENGTH = 16,
 | 
			
		||||
    INPUT = my_procedure_1, OUTPUT = my_procedure_2);
 | 
			
		||||
CREATE TABLE myboxes (id INT4, description box);
 | 
			
		||||
CREATE TYPE box (
 | 
			
		||||
    INTERNALLENGTH = 16,
 | 
			
		||||
    INPUT = my_box_in_function,
 | 
			
		||||
    OUTPUT = my_box_out_function
 | 
			
		||||
);
 | 
			
		||||
 | 
			
		||||
CREATE TABLE myboxes (
 | 
			
		||||
    id integer,
 | 
			
		||||
    description box
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   If <type>box</type>'s internal structure were an array of four
 | 
			
		||||
   <type>float4</>s, we might instead say
 | 
			
		||||
   If the internal structure of <type>box</type> were an array of four
 | 
			
		||||
   <type>float4</> elements, we might instead use
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TYPE box (INTERNALLENGTH = 16,
 | 
			
		||||
    INPUT = my_procedure_1, OUTPUT = my_procedure_2,
 | 
			
		||||
    ELEMENT = float4);
 | 
			
		||||
CREATE TYPE box (
 | 
			
		||||
    INTERNALLENGTH = 16,
 | 
			
		||||
    INPUT = my_box_in_function,
 | 
			
		||||
    OUTPUT = my_box_out_function,
 | 
			
		||||
    ELEMENT = float4
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
   which would allow a box value's component floats to be accessed
 | 
			
		||||
   which would allow a box value's component numbers to be accessed
 | 
			
		||||
   by subscripting.  Otherwise the type behaves the same as before.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
@ -436,20 +413,30 @@ CREATE TYPE box (INTERNALLENGTH = 16,
 | 
			
		||||
   This example creates a large object type and uses it in
 | 
			
		||||
   a table definition:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TYPE bigobj (INPUT = lo_filein, OUTPUT = lo_fileout,
 | 
			
		||||
    INTERNALLENGTH = VARIABLE);
 | 
			
		||||
CREATE TABLE big_objs (id int4, obj bigobj);
 | 
			
		||||
CREATE TYPE bigobj (
 | 
			
		||||
    INPUT = lo_filein, OUTPUT = lo_fileout,
 | 
			
		||||
    INTERNALLENGTH = VARIABLE
 | 
			
		||||
);
 | 
			
		||||
CREATE TABLE big_objs (
 | 
			
		||||
    id integer,
 | 
			
		||||
    obj bigobj
 | 
			
		||||
);
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   This example creates a composite type and uses it in
 | 
			
		||||
   a table function definition:
 | 
			
		||||
   a function definition:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE TYPE compfoo AS (f1 int, f2 text);
 | 
			
		||||
CREATE FUNCTION getfoo() RETURNS SETOF compfoo AS 'SELECT fooid, fooname FROM foo' LANGUAGE SQL;
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   More examples, including suitable input and output functions, are
 | 
			
		||||
   in <xref linkend="extend">.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="SQL-CREATETYPE-compatibility">
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_user.sgml,v 1.25 2003/03/25 16:15:39 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_user.sgml,v 1.26 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -33,16 +33,17 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE USER</command> will add a new user to an instance
 | 
			
		||||
   of <productname>PostgreSQL</productname>. Refer to <xref linkend="user-manag">
 | 
			
		||||
   for information about managing users and authentication.  You must
 | 
			
		||||
   be a database superuser to use this command.
 | 
			
		||||
   <command>CREATE USER</command> adds a new user to a
 | 
			
		||||
   <productname>PostgreSQL</productname> database cluster.  Refer to
 | 
			
		||||
   <xref linkend="user-manag"> and <xref
 | 
			
		||||
   linkend="client-authentication"> for information about managing
 | 
			
		||||
   users and authentication.  You must be a database superuser to use
 | 
			
		||||
   this command.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
  <refsect2>
 | 
			
		||||
   <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
@ -60,9 +61,9 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
       <para>
 | 
			
		||||
        The <literal>SYSID</literal> clause can be used to choose the
 | 
			
		||||
        <productname>PostgreSQL</productname> user ID of the user that
 | 
			
		||||
        is being created. It is not at all necessary that those match
 | 
			
		||||
        the Unix user IDs, but some people choose to keep the numbers
 | 
			
		||||
        the same.
 | 
			
		||||
        is being created. This is not normally not necessary, but may
 | 
			
		||||
        be useful if you need to recreate the owner of an orphaned
 | 
			
		||||
        object.
 | 
			
		||||
       </para>
 | 
			
		||||
       <para>
 | 
			
		||||
        If this is not specified, the highest assigned user ID plus one
 | 
			
		||||
@ -76,10 +77,11 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        Sets the user's password. If you do not plan to use password
 | 
			
		||||
        authentication you can omit this option, but the user
 | 
			
		||||
        won't be able to connect to a password-authenticated server.
 | 
			
		||||
	The password can be set or changed later, using
 | 
			
		||||
	<xref linkend="SQL-ALTERUSER" endterm="SQL-ALTERUSER-title">.
 | 
			
		||||
        authentication you can omit this option, but then the user
 | 
			
		||||
        won't be able to connect if you decide to switch to password
 | 
			
		||||
        authentication.  The password can be set or changed later,
 | 
			
		||||
        using <xref linkend="SQL-ALTERUSER"
 | 
			
		||||
        endterm="SQL-ALTERUSER-title">.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -89,23 +91,22 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
      <term><literal>UNENCRYPTED</></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	These keywords control whether the password is stored
 | 
			
		||||
	encrypted in <literal>pg_shadow</>.  (If neither is specified,
 | 
			
		||||
	the default behavior is determined by the
 | 
			
		||||
	<varname>PASSWORD_ENCRYPTION</varname> server parameter.)  If
 | 
			
		||||
	the presented string is already in MD5-encrypted format, then
 | 
			
		||||
	it is stored as-is, regardless of whether
 | 
			
		||||
	<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified.
 | 
			
		||||
	This allows reloading of encrypted passwords during
 | 
			
		||||
	dump/restore.
 | 
			
		||||
	These key words control whether the password is stored
 | 
			
		||||
	encrypted in the system catalogs.  (If neither is specified,
 | 
			
		||||
	the default behavior is determined by the configuration
 | 
			
		||||
	parameter <varname>password_encryption</varname>.)  If the
 | 
			
		||||
	presented password string is already in MD5-encrypted format,
 | 
			
		||||
	then it is stored encrypted as-is, regardless of whether
 | 
			
		||||
	<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified
 | 
			
		||||
	(since the system cannot decrypt the specified encrypted
 | 
			
		||||
	password string).  This allows reloading of encrypted
 | 
			
		||||
	passwords during dump/restore.
 | 
			
		||||
       </para>
 | 
			
		||||
 | 
			
		||||
       <para>
 | 
			
		||||
        See <xref linkend="client-authentication">
 | 
			
		||||
        for details on how to set up authentication mechanisms.  Note
 | 
			
		||||
        that older clients may lack support for the MD5 authentication
 | 
			
		||||
        mechanism that is needed to work with passwords that are
 | 
			
		||||
        stored encrypted.
 | 
			
		||||
        Note that older clients may lack support for the MD5
 | 
			
		||||
        authentication mechanism that is needed to work with passwords
 | 
			
		||||
        that are stored encrypted.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
@ -160,26 +161,21 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
 </refsect1> 
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <variablelist>
 | 
			
		||||
    <varlistentry>
 | 
			
		||||
     <term><computeroutput>CREATE USER</computeroutput></term>
 | 
			
		||||
     <listitem>
 | 
			
		||||
      <para>
 | 
			
		||||
       Message returned if the command completes successfully.
 | 
			
		||||
       Message returned if the user account was successfully created.
 | 
			
		||||
      </para>
 | 
			
		||||
     </listitem>
 | 
			
		||||
    </varlistentry>
 | 
			
		||||
   </variablelist>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
@ -191,9 +187,12 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 | 
			
		||||
   endterm="SQL-DROPUSER-title"> to remove a user.  Use <xref
 | 
			
		||||
   linkend="SQL-ALTERGROUP" endterm="SQL-ALTERGROUP-title"> to add the
 | 
			
		||||
   user to groups or remove the user from groups.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <productname>PostgreSQL</productname> includes a program <xref
 | 
			
		||||
   linkend="APP-CREATEUSER" endterm="APP-CREATEUSER-title"> that has
 | 
			
		||||
   the same functionality as this command (in fact, it calls this
 | 
			
		||||
   the same functionality as <command>CREATE USER</command> (in fact, it calls this
 | 
			
		||||
   command) but can be run from the command shell.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
@ -216,12 +215,12 @@ CREATE USER davide WITH PASSWORD 'jw8s0F4';
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a user with a password, whose account is valid until the end of 2001.
 | 
			
		||||
   Note that after one second has ticked in 2002, the account is not
 | 
			
		||||
   valid:
 | 
			
		||||
   Create a user with a password that is valid until the end of 2004.
 | 
			
		||||
   After one second has ticked in 2005, the password is no longer
 | 
			
		||||
   valid.
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE USER miriam WITH PASSWORD 'jw8s0F4' VALID UNTIL 'Jan 1 2002';
 | 
			
		||||
CREATE USER miriam WITH PASSWORD 'jw8s0F4' VALID UNTIL '2005-01-01';
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -1,5 +1,5 @@
 | 
			
		||||
<!--
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.21 2002/11/21 23:34:43 petere Exp $
 | 
			
		||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.22 2003/04/22 10:08:08 petere Exp $
 | 
			
		||||
PostgreSQL documentation
 | 
			
		||||
-->
 | 
			
		||||
 | 
			
		||||
@ -8,136 +8,26 @@ PostgreSQL documentation
 | 
			
		||||
  <refentrytitle id="SQL-CREATEVIEW-TITLE">CREATE VIEW</refentrytitle>
 | 
			
		||||
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 | 
			
		||||
 </refmeta>
 | 
			
		||||
 | 
			
		||||
 <refnamediv>
 | 
			
		||||
  <refname>
 | 
			
		||||
   CREATE VIEW
 | 
			
		||||
  </refname>
 | 
			
		||||
  <refpurpose>
 | 
			
		||||
   define a new view
 | 
			
		||||
  </refpurpose>
 | 
			
		||||
  <refname>CREATE VIEW</refname>
 | 
			
		||||
  <refpurpose>define a new view</refpurpose>
 | 
			
		||||
 </refnamediv>
 | 
			
		||||
 | 
			
		||||
 <refsynopsisdiv>
 | 
			
		||||
  <refsynopsisdivinfo>
 | 
			
		||||
   <date>2000-03-25</date>
 | 
			
		||||
  </refsynopsisdivinfo>
 | 
			
		||||
  <synopsis>
 | 
			
		||||
CREATE [ OR REPLACE ] VIEW <replaceable class="PARAMETER">view</replaceable> [ ( <replaceable
 | 
			
		||||
class="PARAMETER">column name list</replaceable> ) ] AS SELECT <replaceable class="PARAMETER">query</replaceable>
 | 
			
		||||
  </synopsis>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEVIEW-1">
 | 
			
		||||
   <refsect2info> 
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Inputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">view</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The name (optionally schema-qualified) of a view to be created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">column name list</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
        An optional list of names to be used for columns of the view.
 | 
			
		||||
	If given, these names override the column names that would be
 | 
			
		||||
	deduced from the SQL query.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><replaceable class="parameter">query</replaceable></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	An SQL query (that is, a <command>SELECT</> statement)
 | 
			
		||||
	which will provide the columns and rows of the view.
 | 
			
		||||
       </para>
 | 
			
		||||
       <para>
 | 
			
		||||
	Refer to <xref linkend="sql-select" endterm="sql-select-title"> for more information
 | 
			
		||||
	about valid arguments.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEVIEW-2">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Outputs
 | 
			
		||||
   </title>
 | 
			
		||||
   <para>
 | 
			
		||||
    <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
CREATE VIEW
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The message returned if the view is successfully created.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
ERROR:  Relation '<replaceable class="parameter">view</replaceable>' already exists
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	This error occurs if the view specified already exists in the database.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term><computeroutput>
 | 
			
		||||
WARNING:  Attribute '<replaceable class="parameter">column</replaceable>' has an unknown type
 | 
			
		||||
       </computeroutput></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	The view will be created having a column with an unknown type
 | 
			
		||||
	if you do not specify it. For example, the following command gives
 | 
			
		||||
	a warning:
 | 
			
		||||
	<programlisting>
 | 
			
		||||
CREATE VIEW vista AS SELECT 'Hello World'
 | 
			
		||||
	</programlisting>
 | 
			
		||||
 | 
			
		||||
	whereas this command does not:
 | 
			
		||||
 | 
			
		||||
	<programlisting>
 | 
			
		||||
CREATE VIEW vista AS SELECT text 'Hello World'
 | 
			
		||||
	</programlisting>
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE [ OR REPLACE ] VIEW <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable
 | 
			
		||||
class="PARAMETER">column_name</replaceable> [, ...] ) ] AS <replaceable class="PARAMETER">query</replaceable>
 | 
			
		||||
</synopsis>
 | 
			
		||||
 </refsynopsisdiv>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEVIEW-1">
 | 
			
		||||
  <refsect1info>
 | 
			
		||||
   <date>2000-03-25</date>
 | 
			
		||||
  </refsect1info>
 | 
			
		||||
  <title>
 | 
			
		||||
   Description
 | 
			
		||||
  </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Description</title>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE VIEW</command> defines a view of a query.
 | 
			
		||||
   The view is not physically materialized. Instead, a query
 | 
			
		||||
   rewrite rule (an <literal>ON SELECT</> rule) is automatically generated to
 | 
			
		||||
   support SELECT operations on views.
 | 
			
		||||
   <command>CREATE VIEW</command> defines a view of a query.  The view
 | 
			
		||||
   is not physically materialized. Instead, the query is run everytime
 | 
			
		||||
   the view is referenced in a query.
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
  <para>
 | 
			
		||||
@ -150,19 +40,87 @@ CREATE VIEW vista AS SELECT text 'Hello World'
 | 
			
		||||
  <para>
 | 
			
		||||
   If a schema name is given (for example, <literal>CREATE VIEW
 | 
			
		||||
   myschema.myview ...</>) then the view is created in the
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema (the one
 | 
			
		||||
   at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
 | 
			
		||||
   specified schema.  Otherwise it is created in the current schema.
 | 
			
		||||
   The view name must be distinct from the name of any other view, table,
 | 
			
		||||
   sequence, or index in the same schema.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEVIEW-3">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    Notes
 | 
			
		||||
   </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Parameters</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The name (optionally schema-qualified) of a view to be created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">column_name</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      An optional list of names to be used for columns of the view.
 | 
			
		||||
      If not given, the column names are deduced from the query.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><replaceable class="parameter">query</replaceable></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      A query (that is, a <command>SELECT</> statement) which will
 | 
			
		||||
      provide the columns and rows of the view.
 | 
			
		||||
     </para>
 | 
			
		||||
 | 
			
		||||
     <para>
 | 
			
		||||
      Refer to <xref linkend="sql-select" endterm="sql-select-title">
 | 
			
		||||
      for more information about valid queries.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Diagnostics</title>
 | 
			
		||||
 | 
			
		||||
  <variablelist>
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>CREATE VIEW</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      Message returned if the view was successfully created.
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
 | 
			
		||||
   <varlistentry>
 | 
			
		||||
    <term><computeroutput>WARNING:  Attribute '<replaceable class="parameter">column</replaceable>' has an unknown type</computeroutput></term>
 | 
			
		||||
    <listitem>
 | 
			
		||||
     <para>
 | 
			
		||||
      The view will be created having a column with an unknown type if
 | 
			
		||||
      you do not specify it. For example, the following command gives
 | 
			
		||||
      this warning:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE VIEW vista AS SELECT 'Hello World'
 | 
			
		||||
</programlisting>
 | 
			
		||||
      whereas this command does not:
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE VIEW vista AS SELECT text 'Hello World'
 | 
			
		||||
</programlisting>
 | 
			
		||||
     </para>
 | 
			
		||||
    </listitem>
 | 
			
		||||
   </varlistentry>
 | 
			
		||||
  </variablelist>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Notes</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    Currently, views are read only: the system will not allow an insert,
 | 
			
		||||
@ -175,100 +133,79 @@ CREATE VIEW vista AS SELECT text 'Hello World'
 | 
			
		||||
   <para>
 | 
			
		||||
    Use the <command>DROP VIEW</command> statement to drop views.
 | 
			
		||||
   </para>
 | 
			
		||||
  </refsect2>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEVIEW-2">
 | 
			
		||||
  <title>
 | 
			
		||||
   Usage
 | 
			
		||||
  </title>
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a view consisting of all Comedy films:
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Examples</title>
 | 
			
		||||
 | 
			
		||||
   <programlisting>
 | 
			
		||||
CREATE VIEW kinds AS
 | 
			
		||||
  <para>
 | 
			
		||||
   Create a view consisting of all comedy films:
 | 
			
		||||
 | 
			
		||||
<programlisting>
 | 
			
		||||
CREATE VIEW comedies AS
 | 
			
		||||
    SELECT *
 | 
			
		||||
    FROM films
 | 
			
		||||
    WHERE kind = 'Comedy';
 | 
			
		||||
 | 
			
		||||
SELECT * FROM kinds;
 | 
			
		||||
 | 
			
		||||
 code  |           title           | did | date_prod  |  kind  | len
 | 
			
		||||
-------+---------------------------+-----+------------+--------+-------
 | 
			
		||||
 UA502 | Bananas                   | 105 | 1971-07-13 | Comedy | 01:22
 | 
			
		||||
 C_701 | There's a Girl in my Soup | 107 | 1970-06-11 | Comedy | 01:36
 | 
			
		||||
(2 rows)
 | 
			
		||||
   </programlisting>
 | 
			
		||||
</programlisting>
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
 
 | 
			
		||||
 <refsect1 id="R1-SQL-CREATEVIEW-3">
 | 
			
		||||
  <title>
 | 
			
		||||
   Compatibility
 | 
			
		||||
  </title>
 | 
			
		||||
  
 | 
			
		||||
  <refsect2 id="R2-SQL-CREATEVIEW-5">
 | 
			
		||||
   <refsect2info>
 | 
			
		||||
    <date>2000-03-25</date>
 | 
			
		||||
   </refsect2info>
 | 
			
		||||
   <title>
 | 
			
		||||
    SQL92
 | 
			
		||||
   </title>
 | 
			
		||||
 <refsect1>
 | 
			
		||||
  <title>Compatibility</title>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    SQL92 specifies some additional capabilities for the
 | 
			
		||||
    <command>CREATE VIEW</command> statement:
 | 
			
		||||
   </para>
 | 
			
		||||
   <synopsis>
 | 
			
		||||
CREATE VIEW <replaceable class="parameter">view</replaceable> [ <replaceable class="parameter">column</replaceable> [, ...] ]
 | 
			
		||||
    AS SELECT <replaceable class="parameter">expression</replaceable> [ AS <replaceable class="parameter">colname</replaceable> ] [, ...]
 | 
			
		||||
    FROM <replaceable class="parameter">table</replaceable> [ WHERE <replaceable class="parameter">condition</replaceable> ]
 | 
			
		||||
  <para>
 | 
			
		||||
   The SQL standard specifies some additional capabilities for the
 | 
			
		||||
   <command>CREATE VIEW</command> statement:
 | 
			
		||||
<synopsis>
 | 
			
		||||
CREATE VIEW <replaceable class="parameter">name</replaceable> [ ( <replaceable class="parameter">column</replaceable> [, ...] ) ]
 | 
			
		||||
    AS query
 | 
			
		||||
    [ WITH [ CASCADE | LOCAL ] CHECK OPTION ]
 | 
			
		||||
   </synopsis>
 | 
			
		||||
</synopsis>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    The optional clauses for the full SQL92 command are:
 | 
			
		||||
  <para>
 | 
			
		||||
   The optional clauses for the full SQL command are:
 | 
			
		||||
 | 
			
		||||
   <variablelist>
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>CHECK OPTION</term>
 | 
			
		||||
      <term><literal>CHECK OPTION</literal></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	This option is to do with updatable views.
 | 
			
		||||
	All <command>INSERT</> and <command>UPDATE</> commands on the view will be
 | 
			
		||||
	checked to ensure data satisfy the view-defining
 | 
			
		||||
	condition. If they do not, the update will be rejected.
 | 
			
		||||
        This option is to do with updatable views.  All
 | 
			
		||||
        <command>INSERT</> and <command>UPDATE</> commands on the view
 | 
			
		||||
        will be checked to ensure data satisfy the view-defining
 | 
			
		||||
        condition (that is, the new data would be visible through the
 | 
			
		||||
        view). If they do not, the update will be rejected.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>LOCAL</term>
 | 
			
		||||
      <term><literal>LOCAL</literal></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Check for integrity on this view.
 | 
			
		||||
        Check for integrity on this view.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
 | 
			
		||||
     <varlistentry>
 | 
			
		||||
      <term>CASCADE</term>
 | 
			
		||||
      <term><literal>CASCADE</literal></term>
 | 
			
		||||
      <listitem>
 | 
			
		||||
       <para>
 | 
			
		||||
	Check for integrity on this view and on any dependent
 | 
			
		||||
	view. CASCADE is assumed if neither CASCADE nor LOCAL is specified.
 | 
			
		||||
        Check for integrity on this view and on any dependent
 | 
			
		||||
        view. <literal>CASCADE</> is assumed if neither
 | 
			
		||||
        <literal>CASCADE</> nor <literal>LOCAL</> is specified.
 | 
			
		||||
       </para>
 | 
			
		||||
      </listitem>
 | 
			
		||||
     </varlistentry>
 | 
			
		||||
    </variablelist>
 | 
			
		||||
   </para>
 | 
			
		||||
   </variablelist>
 | 
			
		||||
  </para>
 | 
			
		||||
 | 
			
		||||
   <para>
 | 
			
		||||
    <command>CREATE OR REPLACE VIEW</command> is a
 | 
			
		||||
    <productname>PostgreSQL</productname> language extension.
 | 
			
		||||
   </para>
 | 
			
		||||
 | 
			
		||||
  </refsect2>
 | 
			
		||||
  <para>
 | 
			
		||||
   <command>CREATE OR REPLACE VIEW</command> is a
 | 
			
		||||
   <productname>PostgreSQL</productname> language extension.
 | 
			
		||||
  </para>
 | 
			
		||||
 </refsect1>
 | 
			
		||||
</refentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user