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

consultation with word definitions.

Backpatch to 9.2.

diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index 6b0793e2197cf82ec08679029aac1d7ea41665ff..67e39b2564d4891b286d5842cf1a1bc8d34a8451 100644 (file)
--- 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";
     pg_collation are ignored.  Thus, a stripped collation
     name such as de_DE 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 default,
     C, and POSIX collations can be used

diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 056e802b40508c651692d00fb132a67fdeb10e2c..c02ed87c41a92222d59f222ce0224dcc1e91c700 100644 (file)
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -92,7 +92,7 @@ su - postgres
      
       You need an ISO/ANSI C compiler (at least
       C89-compliant). Recent
-      versions of GCC are recommendable, but
+      versions of GCC are recommended, but
       PostgreSQL is known to build using a wide variety
       of compilers from different vendors.
      

diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index 2b112932089554e779632d3b6d1961eed2408659..e5a5947ef28946ea2cbcb6138359a4c4315607e9 100644 (file)
--- a/doc/src/sgml/manage-ag.sgml
+++ b/doc/src/sgml/manage-ag.sgml
@@ -44,7 +44,7 @@
    connection level.  If one 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
index 0050e658247826c2e462e5fd6bb872c8572bda60..415749d5424b7c49ecd7011b3d5a8893fd68b2d8 100644 (file)
--- a/doc/src/sgml/passwordcheck.sgml
+++ b/doc/src/sgml/passwordcheck.sgml
@@ -47,7 +47,7 @@
    This limits the usefulness of the passwordcheck
    module, because in that case it can only try to guess the password.
    For this reason, passwordcheck 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 ) than to rely on
    passwords within the database.

diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index 2d9531f08d0402b2d52ec448fc79cda872fa0564..e34dfc0c5aebdc2afec92af19330cd1a23fd8ef0 100644 (file)
--- a/doc/src/sgml/queries.sgml
+++ b/doc/src/sgml/queries.sgml
@@ -1099,7 +1099,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' PARTITION BY/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 ORDER BY clause if you want to be sure the
     results are sorted in a particular way.