<filename>postgresql.conf</filename> without restarting the server.
They can also be set for a particular session in the connection request
packet (for example, via <application>libpq</>'s <literal>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 <filename>postgresql.conf</filename>, send a
<systemitem>SIGHUP</systemitem> signal to the postmaster to cause it to
<para>
These settings can be set from <filename>postgresql.conf</filename>,
or within a session via the <command>SET</> command. Any user is
- allowed to change his session-local value. Changes in
+ allowed to change their session-local value. Changes in
<filename>postgresql.conf</filename> will affect existing sessions
only if no session-local value has been established with <command>SET</>.
</para>
</indexterm>
<para>
- 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
<literal>map</literal>=<replaceable>map-name</replaceable>
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
<command>DROP</>, <command>GRANT</>, <command>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.
</para>
<para>
example, both <literal>schema1</> and <literal>myschema</> can
contain tables named <literal>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.
</para>
</note>
<para>
- 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:
<programlisting>
CREATE DATABASE <replaceable>dbname</> OWNER <replaceable>rolename</>;
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:
<literal>fuzzy</literal> is set if the message has possibly been
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;
<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>
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>
<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>
<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>
<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>
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>
</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>
<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>
</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.
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>
<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>
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 <literal>shoelace</literal> 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:
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.
</para>
<para>
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:
<programlisting>
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;
</programlisting>
- Nobody except him (and the database superusers) can access the
+ Nobody except that user (and the database superusers) can access the
<literal>phone_data</> table. But because of the <command>GRANT</>,
- the secretary can run a <command>SELECT</command> on the
+ the assistant can run a <command>SELECT</command> on the
<literal>phone_number</> view. The rule system will rewrite the
<command>SELECT</command> from <literal>phone_number</> into a
<command>SELECT</command> from <literal>phone_data</>.
Since the user is the owner of
<literal>phone_number</> and therefore the owner of the rule, the
- read access to <literal>phone_data</> is now checked against his
+ read access to <literal>phone_data</> is now checked against the user's
privileges and the query is permitted. The check for accessing
<literal>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.
</para>
<para>
- 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 <literal>phone_number</> data through the secretary's view.
- What the secretary cannot do is to create a view that directly
- accesses <literal>phone_data</>. (Actually he can, but it will not work since
+ can see the <literal>phone_number</> data through the assistant's view.
+ What the assistant cannot do is to create a view that directly
+ accesses <literal>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 <literal>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 <literal>phone_number</> view, the user can revoke the assistant's access. Immediately, any
+ access to the assistant's view would fail.
</para>
<para>
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 <literal>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
<command>GRANT</command> command means, <quote>I trust you</quote>.
If someone you trust does the thing above, it's time to
think it over and then use <command>REVOKE</command>.
<command>SELECT</command> from <literal>phone_number</> into a
<command>SELECT</command> from <literal>phone_data</> and add the
qualification that only entries where <literal>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 <function>NOT LIKE</function> expression.
For example:
the <literal>shoelace</> view to someone else, but only
<literal>SELECT</> on <literal>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 <literal>shoelace_log</> is an unqualified
AND software.hostname = computer.hostname;
</programlisting>
- Since there are appropriate indexes setup, the planner
+ Since there are appropriate indexes set up, the planner
will create a plan of
<literallayout class="monospaced">
<para>
In this case, a regular user cannot reference <literal>customer.credit</>
- directly, but a trusted procedure <literal>show_credit</> allows him
+ directly, but a trusted procedure <literal>show_credit</> allows the user
to print the credit card numbers of customers with some of the digits
masked out.
</para>
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).
</para>
<para>
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.
</para>
<xref linkend="client-authentication">. (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.
<literal>template1</> will be copied by <command>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.
</para>
<para>
projects / postgresql / commitdiff