options can be changed on existing views using <link
      linkend="sql-alterview"><command>ALTER VIEW</command></link>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">query</replaceable></term>
    <listitem>
     <para>
      A <link linkend="sql-select"><command>SELECT</command></link> or
      <link linkend="sql-values"><command>VALUES</command></link> command
      which will provide the columns and rows of the view.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>WITH [ CASCADED | LOCAL ] CHECK OPTION</literal>
      <indexterm zone="sql-createview">
       <primary>CHECK OPTION</primary>
      </indexterm>
      <indexterm zone="sql-createview">
       <primary>WITH CHECK OPTION</primary>
      </indexterm>
    </term>
    <listitem>
     <para>
      This option controls the behavior of automatically updatable views.  When
      this option is specified, <command>INSERT</command>,
      <command>UPDATE</command>, and <command>MERGE</command>
      commands on the view will be checked to ensure that new rows satisfy the
      view-defining condition (that is, the new rows are checked to ensure that
      they are visible through the view).  If they are not, the update will be
      rejected.  If the <literal>CHECK OPTION</literal> is not specified,
      <command>INSERT</command>, <command>UPDATE</command>, and
      <command>MERGE</command> commands on the view are
      allowed to create rows that are not visible through the view.  The
      following check options are supported:

      <variablelist>
       <varlistentry>
        <term><literal>LOCAL</literal></term>
        <listitem>
         <para>
          New rows are only checked against the conditions defined directly in
          the view itself.  Any conditions defined on underlying base views are
          not checked (unless they also specify the <literal>CHECK OPTION</literal>).
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>CASCADED</literal></term>
        <listitem>
         <para>
          New rows are checked against the conditions of the view and all
          underlying base views.  If the <literal>CHECK OPTION</literal> is specified,
          and neither <literal>LOCAL</literal> nor <literal>CASCADED</literal> is specified,
          then <literal>CASCADED</literal> is assumed.
         </para>
        </listitem>
       </varlistentry>
      </variablelist>
     </para>

     <para>
      The <literal>CHECK OPTION</literal> may not be used with <literal>RECURSIVE</literal>
      views.
     </para>

     <para>
      Note that the <literal>CHECK OPTION</literal> is only supported on views that
      are automatically updatable, and do not have <literal>INSTEAD OF</literal>
      triggers or <literal>INSTEAD</literal> rules.  If an automatically updatable
      view is defined on top of a base view that has <literal>INSTEAD OF</literal>
      triggers, then the <literal>LOCAL CHECK OPTION</literal> may be used to check
      the conditions on the automatically updatable view, but the conditions
      on the base view with <literal>INSTEAD OF</literal> triggers will not be
      checked (a cascaded check option will not cascade down to a
      trigger-updatable view, and any check options defined directly on a
      trigger-updatable view will be ignored).  If the view or any of its base
      relations has an <literal>INSTEAD</literal> rule that causes the
      <command>INSERT</command> or <command>UPDATE</command> command to be rewritten, then
      all check options will be ignored in the rewritten query, including any
      checks from automatically updatable views defined on top of the relation
      with the <literal>INSTEAD</literal> rule.  <command>MERGE</command> is not
      supported if the view or any of its base relations have rules.
     </para>
    </listitem>
   </varlistentry>