diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index b4ea227..e174a52 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9257,7 +9257,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
postgresql.conf without restarting the server.
They can also be set for a particular session in the connection request
packet (for example, via libpq's PGOPTIONS
- environment variable); any user can make such a change for his session.
+ environment variable); any user can make such a change for his or her session.
However, these settings never change in a session after it is started.
If you change them in postgresql.conf, send a
SIGHUP signal to the postmaster to cause it to
@@ -9286,7 +9286,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
These settings can be set from postgresql.conf,
or within a session via the SET command. Any user is
- allowed to change his session-local value. Changes in
+ allowed to change a session-local value. Changes in
postgresql.conf will affect existing sessions
only if no session-local value has been established with SET.
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index ba04bdf..c0e5aae 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -692,7 +692,7 @@ local db1,db2,@demodbs all md5
When using an external authentication system like Ident or GSSAPI,
the name of the operating system user that initiated the connection
- might not be the same as the database user he needs to connect as.
+ might not be the same as the database user it needs to connect as.
In this case, a user name map can be applied to map the operating system
user name to a database user. To use user name mapping, specify
map=map-name
@@ -1185,7 +1185,7 @@ omicron bryanh guest1
The drawback of this procedure is that it depends on the integrity
of the client: if the client machine is untrusted or compromised,
an attacker could run just about any program on port 113 and
- return any user name he chooses. This authentication method is
+ return any user name he or she chooses. This authentication method is
therefore only appropriate for closed networks where each client
machine is under tight control and where the database and system
administrators operate in close contact. In other words, you must
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index af1bda6..505b332 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1492,8 +1492,8 @@ REVOKE ALL ON accounts FROM PUBLIC;
DROP, GRANT, REVOKE, etc.)
are always implicit in being the owner,
and cannot be granted or revoked. But the object owner can choose
- to revoke his own ordinary privileges, for example to make a
- table read-only for himself as well as others.
+ to revoke his or her own ordinary privileges, for example to make a
+ table read-only for him- or herself as well as others.
@@ -1819,7 +1819,7 @@ UPDATE 1
example, both schema1 and myschema can
contain tables named mytable. Unlike databases,
schemas are not rigidly separated: a user can access objects in any
- of the schemas in the database he is connected to, if he has
+ of the schemas in the database he or she is connected to, given the
privileges to do so.
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index 78ec509..7f1c506 100644
--- a/doc/src/sgml/manage-ag.sgml
+++ b/doc/src/sgml/manage-ag.sgml
@@ -155,9 +155,9 @@ createdb dbname
- Sometimes you want to create a database for someone else, and have him
- become the owner of the new database, so he can
- configure and manage it himself. To achieve that, use one of the
+ Sometimes you want to create a database for someone else, and have that person
+ become the owner of the new database, so he or she can
+ configure and manage it. To achieve that, use one of the
following commands:
CREATE DATABASE dbname OWNER rolename;
diff --git a/doc/src/sgml/nls.sgml b/doc/src/sgml/nls.sgml
index 3adc1a4..1d33147 100644
--- a/doc/src/sgml/nls.sgml
+++ b/doc/src/sgml/nls.sgml
@@ -115,7 +115,7 @@ msgstr "another translated"
for the translator, such as about expected alignment. The #:
comment indicates the exact location(s) where the message is used
in the source. The translator need not look at the program
- source, but he can if there is doubt about the correct
+ source, but can if there is doubt about the correct
translation. The #, comments contain flags that describe the
message in some way. There are currently two flags:
fuzzy is set if the message has possibly been
diff --git a/doc/src/sgml/ref/alter_user_mapping.sgml b/doc/src/sgml/ref/alter_user_mapping.sgml
index 3cd51b1..79f4a15 100644
--- a/doc/src/sgml/ref/alter_user_mapping.sgml
+++ b/doc/src/sgml/ref/alter_user_mapping.sgml
@@ -38,7 +38,7 @@ ALTER USER MAPPING FOR { user_name
The owner of a foreign server can alter user mappings for that
server for any user. Also, a user can alter a user mapping for
- his own user name if USAGE privilege on the server has
+ his or her own user name if USAGE privilege on the server has
been granted to the user.
diff --git a/doc/src/sgml/ref/create_schema.sgml b/doc/src/sgml/ref/create_schema.sgml
index 79305f1..02248cb 100644
--- a/doc/src/sgml/ref/create_schema.sgml
+++ b/doc/src/sgml/ref/create_schema.sgml
@@ -205,7 +205,7 @@ CREATE VIEW hollywood.winners AS
all objects within it. PostgreSQL
allows schemas to contain objects owned by users other than the
schema owner. This can happen only if the schema owner grants the
- CREATE privilege on his schema to someone else, or a
+ CREATE privilege on the schema to someone else, or a
superuser chooses to create objects in it.
diff --git a/doc/src/sgml/ref/create_user_mapping.sgml b/doc/src/sgml/ref/create_user_mapping.sgml
index bb0c9c0..806163b 100644
--- a/doc/src/sgml/ref/create_user_mapping.sgml
+++ b/doc/src/sgml/ref/create_user_mapping.sgml
@@ -41,7 +41,7 @@ CREATE USER MAPPING FOR { user_name
The owner of a foreign server can create user mappings for that
server for any user. Also, a user can create a user mapping for
- his own user name if USAGE privilege on the server has
+ his or her own user name if USAGE privilege on the server has
been granted to the user.
diff --git a/doc/src/sgml/ref/drop_schema.sgml b/doc/src/sgml/ref/drop_schema.sgml
index 859f17e..dbdb4fc 100644
--- a/doc/src/sgml/ref/drop_schema.sgml
+++ b/doc/src/sgml/ref/drop_schema.sgml
@@ -35,7 +35,7 @@ DROP SCHEMA [ IF EXISTS ] name [, .
A schema can only be dropped by its owner or a superuser. Note that
the owner can drop the schema (and thereby all contained objects)
- even if he does not own some of the objects within the schema.
+ even if he or she does not own some of the objects within the schema.
diff --git a/doc/src/sgml/ref/drop_user_mapping.sgml b/doc/src/sgml/ref/drop_user_mapping.sgml
index ddfad0b..e82ac01 100644
--- a/doc/src/sgml/ref/drop_user_mapping.sgml
+++ b/doc/src/sgml/ref/drop_user_mapping.sgml
@@ -35,7 +35,7 @@ DROP USER MAPPING [ IF EXISTS ] FOR { user_name
The owner of a foreign server can drop user mappings for that server
- for any user. Also, a user can drop a user mapping for his own
+ for any user. Also, a user can drop a user mapping for his or her own
user name if USAGE privilege on the server has been
granted to the user.
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index d9ac8d2..0dd3b01 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -141,7 +141,7 @@ GRANT role_name [, ...] TO
@@ -365,7 +365,7 @@ GRANT role_name [, ...] TO
For servers, this privilege enables the grantee to create foreign
- tables using the server, and also to create, alter, or drop his own
+ tables using the server, and also to create, alter, or drop his or her own
user's user mappings associated with that server.
@@ -438,7 +438,7 @@ GRANT role_name [, ...] TO
A user may perform SELECT, INSERT, etc. on a
- column if he holds that privilege for either the specific column or
+ column if he or she holds that privilege for either the specific column or
its whole table. Granting the privilege at the table level and then
revoking it for one column will not do what you might wish: the
table-level grant is unaffected by a column-level operation.
@@ -628,12 +628,12 @@ GRANT admins TO joe;
PostgreSQL allows an object owner to revoke his
own ordinary privileges: for example, a table owner can make the table
- read-only to himself by revoking his own INSERT,
+ read-only to him- or herself by revoking the INSERT,
UPDATE, DELETE, and TRUNCATE
privileges. This is not possible according to the SQL standard. The
reason is that PostgreSQL treats the owner's
- privileges as having been granted by the owner to himself; therefore he
- can revoke them too. In the SQL standard, the owner's privileges are
+ privileges as having been granted by the owner to him- or herself; therefore they
+ can be revoked too. In the SQL standard, the owner's privileges are
granted by an assumed entity _SYSTEM. Not being
_SYSTEM, the owner cannot revoke these rights.
diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml
index 36c286b..12c5b35 100644
--- a/doc/src/sgml/ref/revoke.sgml
+++ b/doc/src/sgml/ref/revoke.sgml
@@ -193,7 +193,7 @@ REVOKE [ ADMIN OPTION FOR ]
Instead, user A could revoke the grant option from user B and use
the CASCADE option so that the privilege is
in turn revoked from user C. For another example, if both A and B
- have granted the same privilege to C, A can revoke his own grant
+ have granted the same privilege to C, A can revoke his or her own grant
but not B's grant, so C will still effectively have the privilege.
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index fe72fe8..fa6e785e 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -2024,13 +2024,13 @@ SELECT * FROM shoelace;
are used due to rules get checked against the
privileges of the rule owner, not the user invoking the rule.
This means that a user only needs the required privileges
- for the tables/views that he names explicitly in his queries.
+ for the tables/views that he or she names explicitly in queries.
- For example: A user has a list of phone numbers where some of
+ For example: A user u has a list of phone numbers where some of
them are private, the others are of interest for the secretary of the office.
- He can construct the following:
+ u can construct the following:
CREATE TABLE phone_data (person text, phone text, private boolean);
@@ -2040,15 +2040,15 @@ CREATE VIEW phone_number AS
GRANT SELECT ON phone_number TO secretary;
- Nobody except him (and the database superusers) can access the
+ Nobody except u (and the database superusers) can access the
phone_data table. But because of the GRANT,
- the secretary can run a SELECT on the
+ secretary can run a SELECT on the
phone_number view. The rule system will rewrite the
SELECT from phone_number into a
SELECT from phone_data.
Since the user is the owner of
phone_number and therefore the owner of the rule, the
- read access to phone_data is now checked against his
+ read access to phone_data is now checked against u's
privileges and the query is permitted. The check for accessing
phone_number is also performed, but this is done
against the invoking user, so nobody but the user and the
@@ -2056,24 +2056,24 @@ GRANT SELECT ON phone_number TO secretary;
- The privileges are checked rule by rule. So the secretary is for now the
- only one who can see the public phone numbers. But the secretary can setup
+ The privileges are checked rule by rule. So secretary is for now the
+ only one who can see the public phone numbers. But secretary can setup
another view and grant access to that to the public. Then, anyone
- can see the phone_number data through the secretary's view.
- What the secretary cannot do is to create a view that directly
- accesses phone_data. (Actually he can, but it will not work since
+ can see the phone_number data through secretary's view.
+ What secretary cannot do is to create a view that directly
+ accesses phone_data. (Actually secretary can, but it will not work since
every access will be denied during the permission checks.)
- And as soon as the user will notice, that the secretary opened
- his phone_number view, he can revoke his access. Immediately, any
- access to the secretary's view would fail.
+ And as soon as the user notices that secretary opened
+ the phone_number view, u can revoke secretary's access. Immediately, any
+ access to secretary's view would fail.
One might think that this rule-by-rule checking is a security
- hole, but in fact it isn't. But if it did not work this way, the secretary
+ hole, but in fact it isn't. But if it did not work this way, secretary
could set up a table with the same columns as phone_number and
- copy the data to there once per day. Then it's his own data and
- he can grant access to everyone he wants. A
+ copy the data to there once per day. Then it's secretary's own data and
+ he or she can grant access to anyone. A
GRANT command means, I trust you
.
If someone you trust does the thing above, it's time to
think it over and then use REVOKE.
@@ -2124,8 +2124,8 @@ SELECT * FROM phone_number WHERE tricky(person, phone);
the shoelace view to someone else, but only
SELECT on shoelace_log. The rule action to
write log entries will still be executed successfully, and that
- other user could see the log entries. But he cannot create fake
- entries, nor could he manipulate or remove existing ones. In this
+ other user could see the log entries. But he or she cannot create fake
+ entries, nor manipulate or remove existing ones. In this
case, there is no possibility of subverting the rules by convincing
the planner to alter the order of operations, because the only rule
which references shoelace_log is an unqualified
diff --git a/doc/src/sgml/sslinfo.sgml b/doc/src/sgml/sslinfo.sgml
index 22ef439..7e602b9 100644
--- a/doc/src/sgml/sslinfo.sgml
+++ b/doc/src/sgml/sslinfo.sgml
@@ -96,7 +96,7 @@
Returns serial number of current client certificate. The combination of
certificate serial number and certificate issuer is guaranteed to
uniquely identify a certificate (but not its owner — the owner
- ought to regularly change his keys, and get new certificates from the
+ ought to regularly change the keys, and get new certificates from the
issuer).
diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml
index 342fdad..14b4d02 100644
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -143,7 +143,7 @@
Possibly, your site administrator has already created a database
- for your use. He should have told you what the name of your
+ for your use and told you what the name of your
database is. In that case you can omit this step and skip ahead
to the next section.
diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml
index 68220bf..f96ef1d 100644
--- a/doc/src/sgml/xplang.sgml
+++ b/doc/src/sgml/xplang.sgml
@@ -49,7 +49,7 @@
template1 will be copied by CREATE DATABASE.
So the database administrator can
decide which languages are available in which databases and can make
- some languages available by default if he chooses.
+ some languages available by default if he or she chooses.