mirror of
https://github.com/postgres/postgres.git
synced 2025-05-05 09:19:17 +03:00
There is what may actually be a mistake in our markup. The problem is in a situation like <para> <command>FOO</command> is ... there is strictly speaking a line break before "FOO". In the HTML output, this does not appear to be a problem, but in the man page output, this shows up, so you get double blank lines at odd places. So far, we have attempted to work around this with an XSL hack, but that causes other problems, such as creating run-ins in places like <acronym>SQL</acronym> <command>COPY</command> So fix the problem properly by removing the extra whitespace. I only fixed the problems that affect the man page output, not all the places.
125 lines
3.7 KiB
Plaintext
125 lines
3.7 KiB
Plaintext
<!--
|
|
doc/src/sgml/ref/alter_user_mapping.sgml
|
|
PostgreSQL documentation
|
|
-->
|
|
|
|
<refentry id="SQL-ALTERUSERMAPPING">
|
|
<refmeta>
|
|
<refentrytitle>ALTER USER MAPPING</refentrytitle>
|
|
<manvolnum>7</manvolnum>
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>ALTER USER MAPPING</refname>
|
|
<refpurpose>change the definition of a user mapping</refpurpose>
|
|
</refnamediv>
|
|
|
|
<indexterm zone="sql-alterusermapping">
|
|
<primary>ALTER USER MAPPING</primary>
|
|
</indexterm>
|
|
|
|
<refsynopsisdiv>
|
|
<synopsis>
|
|
ALTER USER MAPPING FOR { <replaceable class="parameter">user_name</replaceable> | USER | CURRENT_USER | PUBLIC }
|
|
SERVER <replaceable class="parameter">server_name</replaceable>
|
|
OPTIONS ( [ ADD | SET | DROP ] <replaceable class="PARAMETER">option</replaceable> ['<replaceable class="PARAMETER">value</replaceable>'] [, ... ] )
|
|
</synopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>
|
|
<command>ALTER USER MAPPING</command> changes the definition of a
|
|
user mapping.
|
|
</para>
|
|
|
|
<para>
|
|
The owner of a foreign server can alter user mappings for that
|
|
server for any user. Also, a user can alter a user mapping for
|
|
his own user name if <literal>USAGE</> privilege on the server has
|
|
been granted to the user.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Parameters</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">user_name</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
User name of the mapping. <literal>CURRENT_USER</>
|
|
and <literal>USER</> match the name of the current
|
|
user. <literal>PUBLIC</> is used to match all present and future
|
|
user names in the system.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">server_name</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
Server name of the user mapping.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>OPTIONS ( [ ADD | SET | DROP ] <replaceable class="PARAMETER">option</replaceable> ['<replaceable class="PARAMETER">value</replaceable>'] [, ... ] )</literal></term>
|
|
<listitem>
|
|
<para>
|
|
Change options for the user mapping. The new options override
|
|
any previously specified
|
|
options. <literal>ADD</>, <literal>SET</>, and <literal>DROP</>
|
|
specify the action to be performed. <literal>ADD</> is assumed
|
|
if no operation is explicitly specified. Option names must be
|
|
unique; options are also validated by the server's foreign-data
|
|
wrapper.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
|
|
<para>
|
|
Change the password for user mapping <literal>bob</>, server<literal> foo</>:
|
|
<programlisting>
|
|
ALTER USER MAPPING FOR bob SERVER foo OPTIONS (user 'bob', password 'public');
|
|
</programlisting></para>
|
|
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Compatibility</title>
|
|
|
|
<para>
|
|
<command>ALTER USER MAPPING</command> conforms to ISO/IEC 9075-9
|
|
(SQL/MED). There is a subtle syntax issue: The standard omits
|
|
the <literal>FOR</literal> key word. Since both <literal>CREATE
|
|
USER MAPPING</literal> and <literal>DROP USER MAPPING</literal> use
|
|
<literal>FOR</literal> in analogous positions, and IBM DB2 (being
|
|
the other major SQL/MED implementation) also requires it
|
|
for <literal>ALTER USER MAPPING</literal>, PostgreSQL diverges from
|
|
the standard here in the interest of consistency and
|
|
interoperability.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
|
|
<simplelist type="inline">
|
|
<member><xref linkend="sql-createusermapping"></member>
|
|
<member><xref linkend="sql-dropusermapping"></member>
|
|
</simplelist>
|
|
</refsect1>
|
|
|
|
</refentry>
|