1
0
mirror of https://github.com/postgres/postgres.git synced 2025-12-19 17:02:53 +03:00

Use gender-neutral language in documentation

Based on patch by Thomas Munro <thomas.munro@enterprisedb.com>, although
I rephrased most of the initial work.
This commit is contained in:
Peter Eisentraut
2015-09-21 22:57:29 -04:00
parent 13200777e7
commit 741ccd5015
20 changed files with 57 additions and 58 deletions

View File

@@ -38,7 +38,7 @@ ALTER USER MAPPING FOR { <replaceable class="parameter">user_name</replaceable>
<para>
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 <literal>USAGE</> privilege on the server has
their own user name if <literal>USAGE</> privilege on the server has
been granted to the user.
</para>
</refsect1>

View File

@@ -205,7 +205,7 @@ CREATE VIEW hollywood.winners AS
all objects within it. <productname>PostgreSQL</productname>
allows schemas to contain objects owned by users other than the
schema owner. This can happen only if the schema owner grants the
<literal>CREATE</> privilege on his schema to someone else, or a
<literal>CREATE</> privilege on their schema to someone else, or a
superuser chooses to create objects in it.
</para>

View File

@@ -41,7 +41,7 @@ CREATE USER MAPPING FOR { <replaceable class="parameter">user_name</replaceable>
<para>
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 <literal>USAGE</> privilege on the server has
their own user name if <literal>USAGE</> privilege on the server has
been granted to the user.
</para>
</refsect1>

View File

@@ -35,7 +35,7 @@ DROP SCHEMA [ IF EXISTS ] <replaceable class="PARAMETER">name</replaceable> [, .
<para>
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 they do not own some of the objects within the schema.
</para>
</refsect1>

View File

@@ -35,7 +35,7 @@ DROP USER MAPPING [ IF EXISTS ] FOR { <replaceable class="parameter">user_name</
<para>
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 their own
user name if <literal>USAGE</> privilege on the server has been
granted to the user.
</para>

View File

@@ -141,7 +141,7 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
There is no need to grant privileges to the owner of an object
(usually the user that created it),
as the owner has all privileges by default. (The owner could,
however, choose to revoke some of his own privileges for safety.)
however, choose to revoke some of their own privileges for safety.)
</para>
<para>
@@ -365,7 +365,7 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
</para>
<para>
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 their own
user's user mappings associated with that server.
</para>
</listitem>
@@ -438,9 +438,9 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
<para>
A user may perform <command>SELECT</>, <command>INSERT</>, etc. on a
column if he holds that privilege for either the specific column or
column if they hold 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
revoking it for one column will not do what one might wish: the
table-level grant is unaffected by a column-level operation.
</para>
@@ -626,13 +626,13 @@ GRANT admins TO joe;
</para>
<para>
<productname>PostgreSQL</productname> allows an object owner to revoke his
<productname>PostgreSQL</productname> allows an object owner to revoke their
own ordinary privileges: for example, a table owner can make the table
read-only to himself by revoking his own <literal>INSERT</>,
read-only to themselves by revoking their own <literal>INSERT</>,
<literal>UPDATE</>, <literal>DELETE</>, and <literal>TRUNCATE</>
privileges. This is not possible according to the SQL standard. The
reason is that <productname>PostgreSQL</productname> treats the owner's
privileges as having been granted by the owner to himself; therefore he
privileges as having been granted by the owner to themselves; therefore they
can revoke them too. In the SQL standard, the owner's privileges are
granted by an assumed entity <quote>_SYSTEM</>. Not being
<quote>_SYSTEM</>, the owner cannot revoke these rights.

View File

@@ -193,7 +193,7 @@ REVOKE [ ADMIN OPTION FOR ]
Instead, user A could revoke the grant option from user B and use
the <literal>CASCADE</literal> 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 their own grant
but not B's grant, so C will still effectively have the privilege.
</para>

View File

@@ -77,7 +77,7 @@ RESET ROLE
<para>
In particular, when a superuser chooses to <command>SET ROLE</> to a
non-superuser role, she loses her superuser privileges.
non-superuser role, they lose their superuser privileges.
</para>
<para>