head	1.5;
access;
symbols
	REL9_0_0:1.5
	REL9_1_ALPHA1:1.5
	REL9_0_RC1:1.5
	REL9_0_BETA4:1.5
	REL9_0_STABLE:1.5.0.2
	REL9_0_BETA3:1.5
	REL9_0_BETA2:1.5
	REL8_3_11:1.3
	REL8_4_4:1.4
	REL9_0_BETA1:1.5
	REL9_0_ALPHA5_BRANCH:1.4.0.12
	REL9_0_ALPHA5:1.4
	REL8_3_10:1.3
	REL8_4_3:1.4
	REL9_0_ALPHA4:1.4
	REL9_0_ALPHA4_BRANCH:1.4.0.10
	REL8_5_ALPHA3:1.4
	REL8_5_ALPHA3_BRANCH:1.4.0.8
	REL8_3_9:1.3
	REL8_4_2:1.4
	REL8_5_ALPHA2:1.4
	REL8_5_ALPHA2_BRANCH:1.4.0.6
	REL8_3_8:1.3
	REL8_4_1:1.4
	REL8_5_ALPHA1:1.4
	REL8_5_ALPHA1_BRANCH:1.4.0.4
	REL8_4_STABLE:1.4.0.2
	REL8_4_0:1.4
	REL8_4_RC2:1.4
	REL8_4_RC1:1.4
	REL8_4_BETA2:1.4
	REL8_4_BETA1:1.4
	REL8_3_7:1.3
	REL8_3_6:1.3
	REL8_3_5:1.3
	REL8_3_4:1.3
	REL8_3_3:1.3
	REL8_3_2:1.3
	REL8_3_1:1.3
	REL8_3_STABLE:1.3.0.2
	REL8_3_0:1.3
	REL8_3_RC2:1.3
	REL8_3_RC1:1.3
	REL8_3_BETA4:1.3
	REL8_3_BETA3:1.3
	REL8_3_BETA2:1.3
	REL8_3_BETA1:1.3;
locks; strict;
comment	@# @;


1.5
date	2010.04.03.07.22.58;	author petere;	state Exp;
branches;
next	1.4;

1.4
date	2008.11.14.10.22.46;	author petere;	state Exp;
branches;
next	1.3;

1.3
date	2007.02.14.04.30.26;	author tgl;	state Exp;
branches;
next	1.2;

1.2
date	2007.01.31.23.26.03;	author momjian;	state Exp;
branches;
next	1.1;

1.1
date	2007.01.23.05.07.17;	author tgl;	state Exp;
branches;
next	;


desc
@@


1.5
log
@Remove unnecessary xref endterm attributes and title ids

The endterm attribute is mainly useful when the toolchain does not support
automatic link target text generation for a particular situation.  In  the
past, this was required by the man page tools for all reference page links,
but that is no longer the case, and it now actually gets in the way of
proper automatic link text generation.  The only remaining use cases are
currently xrefs to refsects.
@
text
@<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/create_opfamily.sgml,v 1.4 2008/11/14 10:22:46 petere Exp $
PostgreSQL documentation
-->

<refentry id="SQL-CREATEOPFAMILY">
 <refmeta>
  <refentrytitle>CREATE OPERATOR FAMILY</refentrytitle>
  <manvolnum>7</manvolnum>
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>CREATE OPERATOR FAMILY</refname>
  <refpurpose>define a new operator family</refpurpose>
 </refnamediv>

 <indexterm zone="sql-createopfamily">
  <primary>CREATE OPERATOR FAMILY</primary>
 </indexterm>

 <refsynopsisdiv>
<synopsis>
CREATE OPERATOR FAMILY <replaceable class="parameter">name</replaceable> USING <replaceable class="parameter">index_method</replaceable>
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <command>CREATE OPERATOR FAMILY</command> creates a new operator family.
   An operator family defines a collection of related operator classes,
   and perhaps some additional operators and support functions that are
   compatible with these operator classes but not essential for the
   functioning of any individual index.  (Operators and functions that
   are essential to indexes should be grouped within the relevant operator
   class, rather than being <quote>loose</> in the operator family.
   Typically, single-data-type operators are bound to operator classes,
   while cross-data-type operators can be loose in an operator family
   containing operator classes for both data types.)
  </para>

  <para>
   The new operator family is initially empty.  It should be populated
   by issuing subsequent <command>CREATE OPERATOR CLASS</command> commands
   to add contained operator classes, and optionally
   <command>ALTER OPERATOR FAMILY</command> commands to add <quote>loose</>
   operators and their corresponding support functions.
  </para>

  <para>
   If a schema name is given then the operator family is created in the
   specified schema.  Otherwise it is created in the current schema.
   Two operator families in the same schema can have the same name only if they
   are for different index methods.
  </para>

  <para>
   The user who defines an operator family becomes its owner.  Presently,
   the creating user must be a superuser.  (This restriction is made because
   an erroneous operator family definition could confuse or even crash the
   server.)
  </para>

  <para>
   Refer to <xref linkend="xindex"> for further information.
  </para>
 </refsect1>
  
 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      The name of the operator family to be created.  The name can be
      schema-qualified.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">index_method</replaceable></term>
    <listitem>
     <para>
      The name of the index method this operator family is for.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>
 
 <refsect1>
  <title>Compatibility</title>

  <para>
   <command>CREATE OPERATOR FAMILY</command> is a
   <productname>PostgreSQL</productname> extension.  There is no
   <command>CREATE OPERATOR FAMILY</command> statement in the SQL
   standard.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-alteropfamily"></member>
   <member><xref linkend="sql-dropopfamily"></member>
   <member><xref linkend="sql-createopclass"></member>
   <member><xref linkend="sql-alteropclass"></member>
   <member><xref linkend="sql-dropopclass"></member>
  </simplelist>
 </refsect1>
</refentry>
@


1.4
log
@Set SQL man pages to be section 7 by default, and only transform them to
another section if required by the platform (instead of the old way of
building them in section "l" and always transforming them to the
platform-specific section).

This speeds up the installation on common platforms, and it avoids some
funny business with the man page tools and build process.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/create_opfamily.sgml,v 1.3 2007/02/14 04:30:26 tgl Exp $
d8 1
a8 1
  <refentrytitle id="sql-createopfamily-title">CREATE OPERATOR FAMILY</refentrytitle>
d111 5
a115 5
   <member><xref linkend="sql-alteropfamily" endterm="sql-alteropfamily-title"></member>
   <member><xref linkend="sql-dropopfamily" endterm="sql-dropopfamily-title"></member>
   <member><xref linkend="sql-createopclass" endterm="sql-createopclass-title"></member>
   <member><xref linkend="sql-alteropclass" endterm="sql-alteropclass-title"></member>
   <member><xref linkend="sql-dropopclass" endterm="sql-dropopclass-title"></member>
@


1.3
log
@Minor editorialization on operator-family documentation: put some
copied-and-pasted text in a more useful location.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/create_opfamily.sgml,v 1.2 2007/01/31 23:26:03 momjian Exp $
d9 1
@


1.2
log
@Update reference documentation on may/can/might:

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/create_opfamily.sgml,v 1.1 2007/01/23 05:07:17 tgl Exp $
a65 8
   <command>CREATE OPERATOR FAMILY</command> does not presently check
   whether the operator family definition includes all the operators and
   functions required by the index method, nor whether the operators and
   functions form a self-consistent set.  It is the user's
   responsibility to define a valid operator family.
  </para>

  <para>
@


1.1
log
@Add CREATE/ALTER/DROP OPERATOR FAMILY commands, also COMMENT ON OPERATOR
FAMILY; and add FAMILY option to CREATE OPERATOR CLASS to allow adding a
class to a pre-existing family.  Per previous discussion.  Man, what a
tedious lot of cutting and pasting ...
@
text
@d2 1
a2 1
$PostgreSQL$
d86 1
a86 1
      The name of the operator family to be created.  The name may be
@

