In documentation, change "recommendable" to "recommended", per

bmomjian · bmomjian · commit 30f891151ed6 · 2012-08-14T12:36:46.000-04:00
consultation with word definitions.

Backpatch to 9.2.
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
@@ -563,7 +563,7 @@ SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";
     <literal>pg_collation</literal> are ignored.  Thus, a stripped collation
     name such as <literal>de_DE</literal> can be considered unique
     within a given database even though it would not be unique globally.
-    Use of the stripped collation names is recommendable, since it will
+    Use of the stripped collation names is recommended, since it will
     make one less thing you need to change if you decide to change to
     another database encoding.  Note however that the <literal>default</>,
     <literal>C</>, and <literal>POSIX</> collations can be used
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
@@ -92,7 +92,7 @@ su - postgres
      <para>
       You need an <acronym>ISO</>/<acronym>ANSI</> C compiler (at least
       C89-compliant). Recent
-      versions of <productname>GCC</> are recommendable, but
+      versions of <productname>GCC</> are recommended, but
       <productname>PostgreSQL</> is known to build using a wide variety
       of compilers from different vendors.
      </para>
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
@@ -44,7 +44,7 @@
    connection level.  If one <productname>PostgreSQL</> server
    instance is to house projects or users that should be separate and
    for the most part unaware of each other, it is therefore
-   recommendable to put them into separate databases.  If the projects
+   recommended to put them into separate databases.  If the projects
    or users are interrelated and should be able to use each other's
    resources, they should be put in the same database but possibly
    into separate schemas.  Schemas are a purely logical structure and who can
diff --git a/doc/src/sgml/passwordcheck.sgml b/doc/src/sgml/passwordcheck.sgml
@@ -47,7 +47,7 @@
    This limits the usefulness of the <filename>passwordcheck</filename>
    module, because in that case it can only try to guess the password.
    For this reason, <filename>passwordcheck</filename> is not
-   recommendable if your security requirements are high.
+   recommended if your security requirements are high.
    It is more secure to use an external authentication method such as Kerberos
    (see <xref linkend="client-authentication">) than to rely on
    passwords within the database.
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
@@ -1018,7 +1018,7 @@ SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit
     Currently, window functions always require presorted data, and so the
     query output will be ordered according to one or another of the window
     functions' <literal>PARTITION BY</>/<literal>ORDER BY</> clauses.
-    It is not recommendable to rely on this, however.  Use an explicit
+    It is not recommended to rely on this, however.  Use an explicit
     top-level <literal>ORDER BY</> clause if you want to be sure the
     results are sorted in a particular way.
    </para>
