head	1.6;
access;
symbols
	REL9_0_0:1.6
	REL9_1_ALPHA1:1.6
	REL9_0_RC1:1.6
	REL9_0_BETA4:1.6
	REL9_0_STABLE:1.6.0.2
	REL9_0_BETA3:1.6
	REL9_0_BETA2:1.6
	REL8_3_11:1.3
	REL8_4_4:1.5
	REL9_0_BETA1:1.6
	REL9_0_ALPHA5_BRANCH:1.5.0.12
	REL9_0_ALPHA5:1.5
	REL8_3_10:1.3
	REL8_4_3:1.5
	REL9_0_ALPHA4:1.5
	REL9_0_ALPHA4_BRANCH:1.5.0.10
	REL8_5_ALPHA3:1.5
	REL8_5_ALPHA3_BRANCH:1.5.0.8
	REL8_3_9:1.3
	REL8_4_2:1.5
	REL8_5_ALPHA2:1.5
	REL8_5_ALPHA2_BRANCH:1.5.0.6
	REL8_3_8:1.3
	REL8_4_1:1.5
	REL8_5_ALPHA1:1.5
	REL8_5_ALPHA1_BRANCH:1.5.0.4
	REL8_4_STABLE:1.5.0.2
	REL8_4_0:1.5
	REL8_4_RC2:1.5
	REL8_4_RC1:1.5
	REL8_4_BETA2:1.5
	REL8_4_BETA1:1.5
	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.6
date	2010.04.03.07.22.57;	author petere;	state Exp;
branches;
next	1.5;

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

1.4
date	2008.06.15.01.25.53;	author tgl;	state Exp;
branches;
next	1.3;

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

1.2
date	2007.07.08.17.47.38;	author tgl;	state Exp;
branches;
next	1.1;

1.1
date	2007.07.03.01.30.35;	author neilc;	state Exp;
branches;
next	;


desc
@@


1.6
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/alter_view.sgml,v 1.5 2008/11/14 10:22:45 petere Exp $
PostgreSQL documentation
-->

<refentry id="SQL-ALTERVIEW">
 <refmeta>
  <refentrytitle>ALTER VIEW</refentrytitle>
  <manvolnum>7</manvolnum>
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>ALTER VIEW</refname>
  <refpurpose>change the definition of a view</refpurpose>
 </refnamediv>  
  
 <indexterm zone="sql-alterview">
  <primary>ALTER VIEW</primary>
 </indexterm>

 <refsynopsisdiv>
<synopsis>
ALTER VIEW <replaceable class="parameter">name</replaceable> ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> SET DEFAULT <replaceable class="PARAMETER">expression</replaceable>
ALTER VIEW <replaceable class="parameter">name</replaceable> ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> DROP DEFAULT
ALTER VIEW <replaceable class="parameter">name</replaceable> OWNER TO <replaceable class="PARAMETER">new_owner</replaceable>
ALTER VIEW <replaceable class="parameter">name</replaceable> RENAME TO <replaceable class="parameter">new_name</replaceable>
ALTER VIEW <replaceable class="parameter">name</replaceable> SET SCHEMA <replaceable class="parameter">new_schema</replaceable>
</synopsis>
 </refsynopsisdiv>
  
 <refsect1>
  <title>Description</title>

  <para>
   <command>ALTER VIEW</command> changes various auxiliary properties
   of a view.  (If you want to modify the view's defining query,
   use <command>CREATE OR REPLACE VIEW</>.)
  </para>

  <para>
   You must own the view to use <command>ALTER VIEW</>.
   To change a view's schema, you must also have <literal>CREATE</>
   privilege on the new schema.
   To alter the owner, you must also be a direct or indirect member of the new
   owning role, and that role must have <literal>CREATE</literal> privilege on
   the view's schema.  (These restrictions enforce that altering the owner
   doesn't do anything you couldn't do by dropping and recreating the view.
   However, a superuser can alter ownership of any view anyway.)
  </para>
 </refsect1>
  
 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      The name (optionally schema-qualified) of an existing view.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>SET</literal>/<literal>DROP DEFAULT</literal></term>
    <listitem>
     <para>
      These forms set or remove the default value for a column.
      A default value associated with a view column is
      inserted into <command>INSERT</> statements on the view before
      the view's <literal>ON INSERT</literal> rule is applied, if
      the <command>INSERT</> does not specify a value for the column.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="PARAMETER">new_owner</replaceable></term>
    <listitem>
     <para>
      The user name of the new owner of the view.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_name</replaceable></term>
    <listitem>
     <para>
      The new name for the view.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_schema</replaceable></term>
    <listitem>
     <para>
      The new schema for the view.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   For historical reasons, <command>ALTER TABLE</command> can be used with
   views too; but the only variants of <command>ALTER TABLE</command>
   that are allowed with views are equivalent to the ones shown above.
  </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   To rename the view <literal>foo</literal> to
   <literal>bar</literal>:
<programlisting>
ALTER VIEW foo RENAME TO bar;
</programlisting>
  </para>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   <command>ALTER VIEW</command> is a <productname>PostgreSQL</>
   extension of the SQL standard.
  </para>
 </refsect1>

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

  <simplelist type="inline">
   <member><xref linkend="sql-createview"></member>
   <member><xref linkend="sql-dropview"></member>
  </simplelist>
 </refsect1>
</refentry>
@


1.5
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/alter_view.sgml,v 1.4 2008/06/15 01:25:53 tgl Exp $
d8 1
a8 1
  <refentrytitle id="SQL-ALTERVIEW-TITLE">ALTER VIEW</refentrytitle>
d143 2
a144 2
   <member><xref linkend="sql-createview" endterm="sql-createview-title"></member>
   <member><xref linkend="sql-dropview" endterm="sql-dropview-title"></member>
@


1.4
log
@Rearrange ALTER TABLE syntax processing as per my recent proposal: the
grammar allows ALTER TABLE/INDEX/SEQUENCE/VIEW interchangeably for all
subforms of those commands, and then we sort out what's really legal
at execution time.  This allows the ALTER SEQUENCE/VIEW reference pages
to fully document all the ALTER forms available for sequences and views
respectively, and eliminates a longstanding cause of confusion for users.

The net effect is that the following forms are allowed that weren't before:
	ALTER SEQUENCE OWNER TO
	ALTER VIEW ALTER COLUMN SET/DROP DEFAULT
	ALTER VIEW OWNER TO
	ALTER VIEW SET SCHEMA
(There's no actual functionality gain here, but formerly you had to say
ALTER TABLE instead.)

Interestingly, the grammar tables actually get smaller, probably because
there are fewer special cases to keep track of.

I did not disallow using ALTER TABLE for these operations.  Perhaps we
should, but there's a backwards-compatibility issue if we do; in fact
it would break existing pg_dump scripts.  I did however tighten up
ALTER SEQUENCE and ALTER VIEW to reject non-sequences and non-views
in the new cases as well as a couple of cases where they didn't before.

The patch doesn't change pg_dump to use the new syntaxes, either.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_view.sgml,v 1.3 2007/10/03 16:48:43 tgl Exp $
d9 1
@


1.3
log
@Some editorial improvements for recently-added ALTER SEQUENCE/VIEW
documentation.  Heikki and Tom
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_view.sgml,v 1.2 2007/07/08 17:47:38 tgl Exp $
d23 5
a27 1
ALTER VIEW <replaceable>name</replaceable> RENAME TO <replaceable>newname</replaceable>
d35 14
a48 3
   <command>ALTER VIEW</command> changes the definition of a view.
   The only currently available functionality is to rename the view.
   To execute this command you must be the owner of the view.
d66 32
a97 1
    <term><replaceable class="parameter">newname</replaceable></term>
d100 1
a100 1
      The new name of the view.
d111 3
a113 5
   Some variants of <command>ALTER TABLE</command> can be used with
   views as well; for example, to rename a view it is also
   possible to use <command>ALTER TABLE RENAME</command>.  To change
   the schema or owner of a view, you currently must use <command>ALTER
   TABLE</>.
@


1.2
log
@Fix broken markup.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_view.sgml,v 1.1 2007/07/03 01:30:35 neilc Exp $
d31 3
a33 2
   <command>ALTER VIEW</command> changes the definition of a
   view. To execute this command you must be the owner of the view.
d62 12
@


1.1
log
@Add ALTER VIEW ... RENAME TO, and a RENAME TO clause to ALTER SEQUENCE.
Sequences and views could previously be renamed using ALTER TABLE, but
this was a repeated source of confusion for users. Update the docs,
and psql tab completion. Patch from David Fetter; various minor fixes
by myself.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_view.sgml,v 1.0 Fri Jun 29 2007 fetter Exp $
d70 1
@

