Re: client auth docs seem to have devolved

I wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> This was changed by Peter in
>> commit 56811e57323faa453947eb82f007e323a952e1a1 along with the
>> restructuring. It used to say "the following subsections". So techically I
>> think that change is correct, but that doesn't necessarily make it helpful.
>> But based on how it actually renders, since that section doesn't contain
>> any actual useful info, we should perhaps just remove section 20.3
>> completely. Peter, thoughts?

> Then, URLs pointing to that page (such as Dave evidently has bookmarked)
> would break entirely, which doesn't seem like an improvement.

Also, our docs' own internal links to that section would break --- there
are built-in assumptions that there's one pointable-to place that explains
all the auth methods.

> I suggest changing the sect1's contents to be a list of available auth
> methods, linked to their subsections.  That would provide approximately
> the same quality-of-use as the subsection TOC that used to be there.

Concretely, I propose the attached.  Anybody want to editorialize on
my short descriptions of the auth methods?

            regards, tom lane

diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 36e5a5d..6af1cf5 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -911,8 +911,103 @@ omicron         bryanh                  guest1
 
  <sect1 id="auth-methods">
   <title>Authentication Methods</title>
+
+  <para>
+   <productname>PostgreSQL</productname> provides various methods for
+   authenticating users:
+
+   <itemizedlist>
+    <listitem>
+     <para>
+      <link linkend="auth-trust">Trust authentication</link>, which
+      simply trusts that users are who they say they are.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-password">Password authentication</link>, which
+      requires that the user send a password.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="gssapi-auth">GSSAPI authentication</link>, which
+      relies on a GSSAPI-compatible security library; typically this is
+      used to access an authentication server such as a Kerberos or
+      Microsoft Active Directory server.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="sspi-auth">SSPI authentication</link>, which
+      uses a Windows-specific protocol similar to GSSAPI.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-ident">Ident authentication</link>, which
+      relies on an <quote>Identification Protocol</quote> (RFC 1413)
+      service on the client's machine.  (On local Unix-socket connections,
+      this is treated as peer authentication.)
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-peer">Peer authentication</link>, which
+      relies on operating system facilities to identify the process at the
+      other end of a local connection.  This is not supported for remote
+      connections.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-ldap">LDAP authentication</link>, which
+      relies on an LDAP authentication server.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-radius">RADIUS authentication</link>, which
+      relies on a RADIUS authentication server.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-cert">Certificate authentication</link>, which
+      requires an SSL connection and authenticates users by checking the
+      SSL certificate they send.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-pam">PAM authentication</link>, which
+      relies on a PAM (Pluggable Authentication Modules) library.
+      In most configurations this ends up being a variant of password
+      authentication.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <link linkend="auth-bsd">BSD authentication</link>, which
+      relies on the BSD Authentication framework (currently available
+      only on OpenBSD).
+     </para>
+    </listitem>
+   </itemizedlist>
+  </para>
+
+  <para>
+   Peer authentication is usually recommendable for local connections,
+   though trust authentication might be sufficient in some circumstances.
+   Password authentication is the easiest choice for remote connections;
+   all the other options require some sort of external security
+   infrastructure, usually an authentication server or a certificate
+   authority for issuing SSL certificates.
+  </para>
+
   <para>
-   The following sections describe the authentication methods in more detail.
+   The following sections describe each of these authentication methods
+   in more detail.
   </para>
  </sect1>