From 741ccd5015f82e31f80cdc5d2ae81263ea92d794 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 21 Sep 2015 22:57:29 -0400 Subject: [PATCH] Use gender-neutral language in documentation Based on patch by Thomas Munro , although I rephrased most of the initial work. --- doc/src/sgml/catalogs.sgml | 4 +- doc/src/sgml/client-auth.sgml | 6 +-- doc/src/sgml/ddl.sgml | 6 +-- doc/src/sgml/manage-ag.sgml | 6 +-- doc/src/sgml/nls.sgml | 2 +- doc/src/sgml/plpgsql.sgml | 2 +- doc/src/sgml/ref/alter_user_mapping.sgml | 2 +- doc/src/sgml/ref/create_schema.sgml | 2 +- doc/src/sgml/ref/create_user_mapping.sgml | 2 +- doc/src/sgml/ref/drop_schema.sgml | 2 +- doc/src/sgml/ref/drop_user_mapping.sgml | 2 +- doc/src/sgml/ref/grant.sgml | 14 +++---- doc/src/sgml/ref/revoke.sgml | 2 +- doc/src/sgml/ref/set_role.sgml | 2 +- doc/src/sgml/rules.sgml | 50 +++++++++++------------ doc/src/sgml/sepgsql.sgml | 2 +- doc/src/sgml/sslinfo.sgml | 2 +- doc/src/sgml/start.sgml | 3 +- doc/src/sgml/user-manag.sgml | 2 +- doc/src/sgml/xplang.sgml | 2 +- 20 files changed, 57 insertions(+), 58 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index bad90d4d06..e8bd3a11c8 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -9274,7 +9274,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 their 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 @@ -9303,7 +9303,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 their 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 5eef08fb00..3b2935c4f3 100644 --- a/doc/src/sgml/client-auth.sgml +++ b/doc/src/sgml/client-auth.sgml @@ -690,9 +690,9 @@ local db1,db2,@demodbs all md5 - When using an external authentication system like Ident or GSSAPI, + When using an external authentication system such as 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 that is to be 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 they choose. 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 ab0c19122a..61bf671c9f 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 their own ordinary privileges, for example to make a + table read-only for themselves as well as others. @@ -1816,7 +1816,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 they are connected to, if they have privileges to do so. diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml index 260cf36104..fe1a6355c4 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 them + become the owner of the new database, so they can + configure and manage it themselves. 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 3adc1a41e1..1d331473af 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/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index a27bbc53a2..978624288e 100644 --- a/doc/src/sgml/plpgsql.sgml +++ b/doc/src/sgml/plpgsql.sgml @@ -3904,7 +3904,7 @@ CREATE FUNCTION emp_stamp() RETURNS trigger AS $emp_stamp$ RAISE EXCEPTION '% cannot have null salary', NEW.empname; END IF; - -- Who works for us when she must pay for it? + -- Who works for us when they must pay for it? IF NEW.salary < 0 THEN RAISE EXCEPTION '% cannot have a negative salary', NEW.empname; END IF; diff --git a/doc/src/sgml/ref/alter_user_mapping.sgml b/doc/src/sgml/ref/alter_user_mapping.sgml index 3cd51b1413..3a908130d8 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 + their 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 79305f15dd..554a4483c5 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 their 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 bb0c9c0b03..44fe302fb5 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 + their 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 859f17e185..e3071227fe 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 they do 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 ddfad0bcad..eb4c320293 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 their 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 d9ac8d20f2..cd8f3f50ba 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 their own user's user mappings associated with that server. @@ -438,9 +438,9 @@ 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 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. @@ -626,13 +626,13 @@ GRANT admins TO joe; - PostgreSQL allows an object owner to revoke his + PostgreSQL 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 INSERT, + read-only to themselves by revoking their own 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 + 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 _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 36c286bf0d..fc00129620 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 their own grant but not B's grant, so C will still effectively have the privilege. diff --git a/doc/src/sgml/ref/set_role.sgml b/doc/src/sgml/ref/set_role.sgml index 8e2deb7635..aff3792199 100644 --- a/doc/src/sgml/ref/set_role.sgml +++ b/doc/src/sgml/ref/set_role.sgml @@ -77,7 +77,7 @@ RESET ROLE In particular, when a superuser chooses to SET ROLE to a - non-superuser role, she loses her superuser privileges. + non-superuser role, they lose their superuser privileges. diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index fe72fe8a69..ca1b767d69 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1652,7 +1652,7 @@ CREATE RULE shoelace_ins AS ON INSERT TO shoelace Now assume that once in a while, a pack of shoelaces arrives at the shop and a big parts list along with it. But you don't want to manually update the shoelace view every - time. Instead we setup two little tables: one where you can + time. Instead we set up two little tables: one where you can insert the items from the part list, and one with a special trick. The creation commands for these are: @@ -2023,57 +2023,57 @@ SELECT * FROM shoelace; behavior of the default access control system. Relations that 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. + This means that users only need the required privileges + for the tables/views that are explicitly named in their queries. For example: A user 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: + them are private, the others are of interest for the assistant of the office. + The user can construct the following: CREATE TABLE phone_data (person text, phone text, private boolean); CREATE VIEW phone_number AS SELECT person, CASE WHEN NOT private THEN phone END AS phone FROM phone_data; -GRANT SELECT ON phone_number TO secretary; +GRANT SELECT ON phone_number TO assistant; - Nobody except him (and the database superusers) can access the + Nobody except that user (and the database superusers) can access the phone_data table. But because of the GRANT, - the secretary can run a SELECT on the + the assistant 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 the user'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 - secretary can use it. + assistant can use it. - 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 the assistant is for now the + only one who can see the public phone numbers. But the assistant can set up 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 the assistant's view. + What the assistant cannot do is to create a view that directly + accesses phone_data. (Actually the assistant 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 the assistant opened + their phone_number view, the user can revoke the assistant's access. Immediately, any + access to the assistant'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, the assistant 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 the assistant's own data and + the assistant can grant access to everyone they want. 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. @@ -2093,7 +2093,7 @@ CREATE VIEW phone_number AS SELECT from phone_number into a SELECT from phone_data and add the qualification that only entries where phone does not begin - with 412 are wanted. But if the user can create his or her own functions, + with 412 are wanted. But if the user can create their own functions, it is not difficult to convince the planner to execute the user-defined function prior to the NOT LIKE expression. For example: @@ -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 they could not create fake + entries, nor could they 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 @@ -2333,7 +2333,7 @@ DELETE FROM software WHERE computer.hostname = 'mypc.local.net' AND software.hostname = computer.hostname; - Since there are appropriate indexes setup, the planner + Since there are appropriate indexes set up, the planner will create a plan of diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml index 6889e428a4..18279f7353 100644 --- a/doc/src/sgml/sepgsql.sgml +++ b/doc/src/sgml/sepgsql.sgml @@ -570,7 +570,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; In this case, a regular user cannot reference customer.credit - directly, but a trusted procedure show_credit allows him + directly, but a trusted procedure show_credit allows the user to print the credit card numbers of customers with some of the digits masked out. diff --git a/doc/src/sgml/sslinfo.sgml b/doc/src/sgml/sslinfo.sgml index 4203d8fb8a..a4ce7e8d2c 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 their keys, and get new certificates from the issuer). diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml index 342fdad91c..b4cb7981be 100644 --- a/doc/src/sgml/start.sgml +++ b/doc/src/sgml/start.sgml @@ -143,8 +143,7 @@ Possibly, your site administrator has already created a database - for your use. He should have told you what the name of your - database is. In that case you can omit this step and skip ahead + for your use. In that case you can omit this step and skip ahead to the next section. diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml index 177ac7aa8c..6476e3f9d8 100644 --- a/doc/src/sgml/user-manag.sgml +++ b/doc/src/sgml/user-manag.sgml @@ -129,7 +129,7 @@ SELECT rolname FROM pg_roles; . (Thus, a client is not limited to connect as the role matching its operating system user, just as a person's login name - need not match her real name.) Since the role + need not match his or her real name.) Since the role identity determines the set of privileges available to a connected client, it is important to carefully configure privileges when setting up a multiuser environment. diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml index 68220bf633..9fa97d4c70 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 desired. -- 2.40.0