Subject: postgres-9.1beta3 typo: recommendable --> recommended

From: Gavin Flower <[email-masked]>
Date: Fri, 29 Jul 2011 18:42:57 +1200

/postgres-9.1/share/doc/html/manage-ag-overview.html
In the folowing partagrasoh 'recommendable' should be 'recommended'.

[...]
When connecting to the database server, a client must specify in its 
connection request the name of the database it wants to connect to. It 
is not possible to access more than one database per connection. 
However, an application is not restricted in the number of connections 
it opens to the same or other databases. Databases are physically 
separated and access control is managed at the 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 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 access what 
is managed by the privilege system. More information about managing 
schemas is in Section 5.7.
[...]

---

From: Tom Lane <[email-masked]>
Date: Fri, 29 Jul 2011 10:03:16 -0400

> In the folowing partagrasoh 'recommendable' should be 'recommended'.

Seems perfectly ok as-is to me ...

			regards, tom lane

---

From: Dave Page <[email-masked]>
Date: Fri, 29 Jul 2011 15:13:50 +0100

> Seems perfectly ok as-is to me ...

Sounds hideous to me. I ran it past one of our tech writers (Susan
Douglas), who rewrote the sentence as:

If a single PostgreSQL server instance is to house projects or users
that should be separate (for the most part unaware of each other), we
recommend storing them in separate databases.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Alvaro Herrera <[email-masked]>
Date: Fri, 29 Jul 2011 10:41:47 -0400

> recommend storing them in separate databases.

Except that we don't use the first person in docs, do we?

-- 
Álvaro Herrera <[email-masked]>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---

From: Dave Page <[email-masked]>
Date: Fri, 29 Jul 2011 15:45:01 +0100

> Except that we don't use the first person in docs, do we?

That's easily changed.

---

From: "Kevin Grittner" <[email-masked]>
Date: Fri, 29 Jul 2011 09:50:25 -0500

> Except that we don't use the first person in docs, do we?
 
find doc/src/sgml -name '*.sgml' | xargs cat | egrep -ci '\bwe\b'
786
 
-Kevin

---

From: Jaime Casanova <[email-masked]>
Date: Mon, 1 Aug 2011 23:53:25 -0500

On Fri, Jul 29, 2011 at 1:42 AM, Gavin Flower
<[email-masked]> wrote:
> Databases are physically separated and access
> control is managed at the 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 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.
> [...]
>

maybe it's because i'm not a natural english speaker but this sounds
like we are recommended to put the users in another database. probably
it is refering to the user's resources... maybe we can make it more
explicit?

-- 
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

---

From: Robert Haas <[email-masked]>
Date: Mon, 15 Aug 2011 13:59:43 -0400

> it is refering to the user's resources... maybe we can make it more

The only thing that seems weird about it to me is that recommendable
is a word that is almost never used by native English speakers.  Or at
least not the native English speakers I know.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 10 Aug 2012 22:36:43 -0400

> least not the native English speakers I know.

I did some research on this and this was the best description I could
find was:

	http://forum.wordreference.com/showthread.php?t=693689
	
	If you want to suggest others use it, it is recommended. If you want to
	suggest others tell their friends and aquaintances to use it, it would
	be recommendable. 

I think all doc mentions of 'recommendable' should be changed to
'recommended'.

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 14 Aug 2012 12:36:49 -0400

> I think all doc mentions of 'recommendable' should be changed to

Done with the attached patch, backpatched to 9.2.

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
new file mode 100644
index 6b0793e..67e39b2
*** a/doc/src/sgml/charset.sgml
--- b/doc/src/sgml/charset.sgml
*************** SELECT * FROM test1 ORDER BY a || b COLL
*** 563,569 ****
      <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
      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
--- 563,569 ----
      <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 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
new file mode 100644
index 056e802..c02ed87
*** a/doc/src/sgml/installation.sgml
--- b/doc/src/sgml/installation.sgml
*************** su - postgres
*** 92,98 ****
       <para>
        You need an <acronym>ISO</>/<acronym>ANSI</> C compiler (at least
        C89-compliant). Recent
!       versions of <productname>GCC</> are recommendable, but
        <productname>PostgreSQL</> is known to build using a wide variety
        of compilers from different vendors.
       </para>
--- 92,98 ----
       <para>
        You need an <acronym>ISO</>/<acronym>ANSI</> C compiler (at least
        C89-compliant). Recent
!       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
new file mode 100644
index 2b11293..e5a5947
*** a/doc/src/sgml/manage-ag.sgml
--- b/doc/src/sgml/manage-ag.sgml
***************
*** 44,50 ****
     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
     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
--- 44,50 ----
     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
!    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
new file mode 100644
index 0050e65..415749d
*** a/doc/src/sgml/passwordcheck.sgml
--- b/doc/src/sgml/passwordcheck.sgml
***************
*** 47,53 ****
     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.
     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.
--- 47,53 ----
     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
!    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
new file mode 100644
index 2d9531f..e34dfc0
*** a/doc/src/sgml/queries.sgml
--- b/doc/src/sgml/queries.sgml
*************** SELECT product_id, p.name, (sum(s.units)
*** 1099,1105 ****
      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
      top-level <literal>ORDER BY</> clause if you want to be sure the
      results are sorted in a particular way.
     </para>
--- 1099,1105 ----
      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 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>