On Fri, Aug 10, 2012 at 10:36:43PM -0400, Bruce Momjian wrote:
> On Mon, Aug 15, 2011 at 01:59:43PM -0400, Robert Haas wrote:
> > On Tue, Aug 2, 2011 at 12:53 AM, Jaime Casanova <ja...@2ndquadrant.com>
> > wrote:
> > > On Fri, Jul 29, 2011 at 1:42 AM, Gavin Flower
> > > <gavinflo...@archidevsys.co.nz> wrote:
> > >> /postgres-9.1/share/doc/html/manage-ag-overview.html
> > >> In the folowing partagrasoh 'recommendable' should be 'recommended'.
> > >>
> > >> [...]
> > >> 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?
> >
> > 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.
>
> 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'.
Done with the attached patch, backpatched to 9.2.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ 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>
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
