diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index ac2f184ec3..fb74988f1a 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -1,4 +1,4 @@
-
+
Localization</>
@@ -72,14 +72,15 @@ initdb --locale=sv_SE
locale then the specifications look like this:
<literal>cs_CZ.ISO8859-2</>. What locales are available under what
names on your system depends on what was provided by the operating
- system vendor and what was installed.
+ system vendor and what was installed. (On most systems, the command
+ <literal>locale -a</> will provide a list of available locales.)
</para>
<para>
Occasionally it is useful to mix rules from several locales, e.g.,
use English collation rules but Spanish messages. To support that, a
set of locale subcategories exist that control only a certain
- aspect of the localization rules.
+ aspect of the localization rules:
<informaltable>
<tgroup cols="2">
@@ -90,7 +91,7 @@ initdb --locale=sv_SE
</row>
<row>
<entry><envar>LC_CTYPE</></>
- <entry>Character classification (What is a letter? The upper-case equivalent?)</>
+ <entry>Character classification (What is a letter? Its upper-case equivalent?)</>
</row>
<row>
<entry><envar>LC_MESSAGES</></>
@@ -154,7 +155,7 @@ initdb --locale=sv_SE
environment variables seen by the server, not by the environment
of any client. Therefore, be careful to configure the correct locale settings
before starting the server. A consequence of this is that if
- client and server are set up to different locales, messages may
+ client and server are set up in different locales, messages may
appear in different languages depending on where they originated.
</para>
@@ -181,7 +182,7 @@ initdb --locale=sv_SE
</note>
<para>
- To enable messages translated to the user's preferred language,
+ To enable messages to be translated to the user's preferred language,
<acronym>NLS</acronym> must have been enabled at build time. This
choice is independent of the other locale support.
</para>
@@ -234,8 +235,8 @@ initdb --locale=sv_SE
changed without repeating <command>initdb</>. Other locale
settings including <envar>LC_MESSAGES</> and <envar>LC_MONETARY</>
are initially determined by the environment the server is started
- in. You can check the <envar>LC_COLLATE</> and <envar>LC_CTYPE</>
- settings of a database using the <command>SHOW</> command.
+ in, but can be changed on-the-fly. You can check the active locale
+ settings using the <command>SHOW</> command.
</para>
<para>
@@ -256,9 +257,9 @@ initdb --locale=sv_SE
Maintaining catalogs of message translations requires the on-going
efforts of many volunteers that want to see
<productname>PostgreSQL</> speak their preferred language well.
- If messages in your language is currently not available or fully
+ If messages in your language are currently not available or not fully
translated, your assistance would be appreciated. If you want to
- help, refer to the <xref linkend="nls"> or write to the developers'
+ help, refer to <xref linkend="nls"> or write to the developers'
mailing list.
</para>
</sect2>
@@ -298,128 +299,128 @@ initdb --locale=sv_SE
<title>Server Character Sets
-
- Name
- Description
-
+
+ Name
+ Description
+
-
- SQL_ASCII
- ASCII
-
-
- EUC_JP
- Japanese EUC
-
-
- EUC_CN
- Chinese EUC
-
-
- EUC_KR
- Korean EUC
-
-
- JOHAB
- Korean EUC (Hangle base)
-
-
- EUC_TW
- Taiwan EUC
-
-
- UNICODE
- Unicode (UTF-8)
-
-
- MULE_INTERNAL
- Mule internal code
-
-
- LATIN1
- ISO 8859-1/ECMA 94 (Latin alphabet no.1)
-
-
- LATIN2
- ISO 8859-2/ECMA 94 (Latin alphabet no.2)
-
-
- LATIN3
- ISO 8859-3/ECMA 94 (Latin alphabet no.3)
-
-
- LATIN4
- ISO 8859-4/ECMA 94 (Latin alphabet no.4)
-
-
- LATIN5
- ISO 8859-9/ECMA 128 (Latin alphabet no.5)
-
-
- LATIN6
- ISO 8859-10/ECMA 144 (Latin alphabet no.6)
-
-
- LATIN7
- ISO 8859-13 (Latin alphabet no.7)
-
-
- LATIN8
- ISO 8859-14 (Latin alphabet no.8)
-
-
- LATIN9
- ISO 8859-15 (Latin alphabet no.9)
-
-
- LATIN10
- ISO 8859-16/ASRO SR 14111 (Latin alphabet no.10)
-
-
- ISO_8859_5
- ISO 8859-5/ECMA 113 (Latin/Cyrillic)
-
-
- ISO_8859_6
- ISO 8859-6/ECMA 114 (Latin/Arabic)
-
-
- ISO_8859_7
- ISO 8859-7/ECMA 118 (Latin/Greek)
-
-
- ISO_8859_8
- ISO 8859-8/ECMA 121 (Latin/Hebrew)
-
-
- KOI8
- KOI8-R(U)
-
-
- ALT
- Windows CP866
-
-
- WIN874
- Windows CP874 (Thai)
-
-
- WIN1250
- Windows CP1250
-
-
- WIN
- Windows CP1251
-
-
- WIN1256
- Windows CP1256 (Arabic)
-
-
- TCVN
- TCVN-5712/Windows CP1258 (Vietnamese)
-
+
+ SQL_ASCII
+ ASCII
+
+
+ EUC_JP
+ Japanese EUC
+
+
+ EUC_CN
+ Chinese EUC
+
+
+ EUC_KR
+ Korean EUC
+
+
+ JOHAB
+ Korean EUC (Hangle base)
+
+
+ EUC_TW
+ Taiwan EUC
+
+
+ UNICODE
+ Unicode (UTF-8)
+
+
+ MULE_INTERNAL
+ Mule internal code
+
+
+ LATIN1
+ ISO 8859-1/ECMA 94 (Latin alphabet no.1)
+
+
+ LATIN2
+ ISO 8859-2/ECMA 94 (Latin alphabet no.2)
+
+
+ LATIN3
+ ISO 8859-3/ECMA 94 (Latin alphabet no.3)
+
+
+ LATIN4
+ ISO 8859-4/ECMA 94 (Latin alphabet no.4)
+
+
+ LATIN5
+ ISO 8859-9/ECMA 128 (Latin alphabet no.5)
+
+
+ LATIN6
+ ISO 8859-10/ECMA 144 (Latin alphabet no.6)
+
+
+ LATIN7
+ ISO 8859-13 (Latin alphabet no.7)
+
+
+ LATIN8
+ ISO 8859-14 (Latin alphabet no.8)
+
+
+ LATIN9
+ ISO 8859-15 (Latin alphabet no.9)
+
+
+ LATIN10
+ ISO 8859-16/ASRO SR 14111 (Latin alphabet no.10)
+
+
+ ISO_8859_5
+ ISO 8859-5/ECMA 113 (Latin/Cyrillic)
+
+
+ ISO_8859_6
+ ISO 8859-6/ECMA 114 (Latin/Arabic)
+
+
+ ISO_8859_7
+ ISO 8859-7/ECMA 118 (Latin/Greek)
+
+
+ ISO_8859_8
+ ISO 8859-8/ECMA 121 (Latin/Hebrew)
+
+
+ KOI8
+ KOI8-R(U)
+
+
+ ALT
+ Windows CP866
+
+
+ WIN874
+ Windows CP874 (Thai)
+
+
+ WIN1250
+ Windows CP1250
+
+
+ WIN
+ Windows CP1251
+
+
+ WIN1256
+ Windows CP1256 (Arabic)
+
+
+ TCVN
+ TCVN-5712/Windows CP1258 (Vietnamese)
+
@@ -498,6 +499,31 @@ $ psql -l
(9 rows)
+
+
+
+ Although you can specify any encoding you want for a database, it is
+ unwise to choose an encoding that is not what is expected by the locale
+ you have selected. The LC_COLLATE and
+ LC_CTYPE settings imply a particular encoding,
+ and locale-dependent operations (such as sorting) are likely to
+ misinterpret data that is in an incompatible encoding.
+
+
+
+ Since these locale settings are frozen by initdb, the
+ apparent flexibility to use different encodings in different databases
+ of a cluster is more theoretical than real. It is likely that these
+ mechanisms will be revisited in future versions of
+ PostgreSQL.
+
+
+
+ One way to use multiple encodings safely is to set the locale to
+ C or POSIX during initdb, thus
+ disabling any real locale awareness.
+
+
@@ -518,206 +544,206 @@ $ psql -l
Client/Server Character Set Conversions
-
- Server Character Set
- Available Client Character Sets
-
+
+ Server Character Set
+ Available Client Character Sets
+
-
- SQL_ASCII
- SQL_ASCII, UNICODE, MULE_INTERNAL
-
-
-
- EUC_JP
- EUC_JP, SJIS,
- UNICODE, MULE_INTERNAL
-
-
-
- EUC_CN
- EUC_CN, UNICODE, MULE_INTERNAL
-
-
-
- EUC_KR
- EUC_KR, UNICODE, MULE_INTERNAL
-
-
-
- JOHAB
- JOHAB, UNICODE
-
-
-
- EUC_TW
- EUC_TW, BIG5,
- UNICODE, MULE_INTERNAL
-
-
-
- LATIN1
- LATIN1, UNICODE
- MULE_INTERNAL
-
-
-
- LATIN2
- LATIN2, WIN1250,
- UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN3
- LATIN3, UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN4
- LATIN4, UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN5
- LATIN5, UNICODE
-
-
-
- LATIN6
- LATIN6, UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN7
- LATIN7, UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN8
- LATIN8, UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN9
- LATIN9, UNICODE,
- MULE_INTERNAL
-
-
-
- LATIN10
- LATIN10, UNICODE,
- MULE_INTERNAL
-
-
-
- ISO_8859_5
- ISO_8859_5,
- UNICODE,
- MULE_INTERNAL,
- WIN,
- ALT,
- KOI8
-
-
-
- ISO_8859_6
- ISO_8859_6,
- UNICODE
-
-
-
- ISO_8859_7
- ISO_8859_7,
- UNICODE
-
-
-
- ISO_8859_8
- ISO_8859_8,
- UNICODE
-
-
-
- UNICODE
-
- EUC_JP, SJIS,
- EUC_KR, UHC, JOHAB,
- EUC_CN, GBK,
- EUC_TW, BIG5,
- LATIN1 to LATIN10,
- ISO_8859_5,
- ISO_8859_6,
- ISO_8859_7,
- ISO_8859_8,
- WIN, ALT,
- KOI8,
- WIN1256,
- TCVN,
- WIN874,
- GB18030,
- WIN1250
-
-
-
- MULE_INTERNAL
- EUC_JP, SJIS, EUC_KR, EUC_CN,
- EUC_TW, BIG5, LATIN1 to LATIN5,
- WIN, ALT,
- WIN1250,
- BIG5, ISO_8859_5, KOI8
-
-
- KOI8
- ISO_8859_5, WIN,
- ALT, KOI8,
- UNICODE, MULE_INTERNAL
-
-
-
- ALT
- ISO_8859_5, WIN,
- ALT, KOI8,
- UNICODE, MULE_INTERNAL
-
-
-
- WIN874
- WIN874,
- UNICODE
-
-
-
- WIN1250
- LATIN2, WIN1250,
+
+ SQL_ASCII
+ SQL_ASCII, UNICODE, MULE_INTERNAL
+
+
+
+ EUC_JP
+ EUC_JP, SJIS,
UNICODE, MULE_INTERNAL
-
-
-
- WIN
- ISO_8859_5, WIN,
- ALT, KOI8,
- UNICODE, MULE_INTERNAL
-
-
-
- WIN1256
- WIN1256,
- UNICODE
-
-
-
- TCVN
- TCVN,
- UNICODE
-
-
+
+
+
+ EUC_CN
+ EUC_CN, UNICODE, MULE_INTERNAL
+
+
+
+ EUC_KR
+ EUC_KR, UNICODE, MULE_INTERNAL
+
+
+
+ JOHAB
+ JOHAB, UNICODE
+
+
+
+ EUC_TW
+ EUC_TW, BIG5,
+ UNICODE, MULE_INTERNAL
+
+
+
+ LATIN1
+ LATIN1, UNICODE
+ MULE_INTERNAL
+
+
+
+ LATIN2
+ LATIN2, WIN1250,
+ UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN3
+ LATIN3, UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN4
+ LATIN4, UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN5
+ LATIN5, UNICODE
+
+
+
+ LATIN6
+ LATIN6, UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN7
+ LATIN7, UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN8
+ LATIN8, UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN9
+ LATIN9, UNICODE,
+ MULE_INTERNAL
+
+
+
+ LATIN10
+ LATIN10, UNICODE,
+ MULE_INTERNAL
+
+
+
+ ISO_8859_5
+ ISO_8859_5,
+ UNICODE,
+ MULE_INTERNAL,
+ WIN,
+ ALT,
+ KOI8
+
+
+
+ ISO_8859_6
+ ISO_8859_6,
+ UNICODE
+
+
+
+ ISO_8859_7
+ ISO_8859_7,
+ UNICODE
+
+
+
+ ISO_8859_8
+ ISO_8859_8,
+ UNICODE
+
+
+
+ UNICODE
+
+ EUC_JP, SJIS,
+ EUC_KR, UHC, JOHAB,
+ EUC_CN, GBK,
+ EUC_TW, BIG5,
+ LATIN1 to LATIN10,
+ ISO_8859_5,
+ ISO_8859_6,
+ ISO_8859_7,
+ ISO_8859_8,
+ WIN, ALT,
+ KOI8,
+ WIN1256,
+ TCVN,
+ WIN874,
+ GB18030,
+ WIN1250
+
+
+
+ MULE_INTERNAL
+ EUC_JP, SJIS, EUC_KR, EUC_CN,
+ EUC_TW, BIG5, LATIN1 to LATIN5,
+ WIN, ALT,
+ WIN1250,
+ BIG5, ISO_8859_5, KOI8
+
+
+ KOI8
+ ISO_8859_5, WIN,
+ ALT, KOI8,
+ UNICODE, MULE_INTERNAL
+
+
+
+ ALT
+ ISO_8859_5, WIN,
+ ALT, KOI8,
+ UNICODE, MULE_INTERNAL
+
+
+
+ WIN874
+ WIN874,
+ UNICODE
+
+
+
+ WIN1250
+ LATIN2, WIN1250,
+ UNICODE, MULE_INTERNAL
+
+
+
+ WIN
+ ISO_8859_5, WIN,
+ ALT, KOI8,
+ UNICODE, MULE_INTERNAL
+
+
+
+ WIN1256
+ WIN1256,
+ UNICODE
+
+
+
+ TCVN
+ TCVN,
+ UNICODE
+
+
@@ -731,11 +757,11 @@ $ psql -l
- Using the \encoding command in
- psql.
- \encoding allows you to change client
- encoding on the fly. For
- example, to change the encoding to SJIS, type:
+ Using the \encoding command in
+ psql.
+ \encoding allows you to change client
+ encoding on the fly. For
+ example, to change the encoding to SJIS, type:
\encoding SJIS
@@ -745,27 +771,27 @@ $ psql -l
- Using libpq functions.
- \encoding actually calls
- PQsetClientEncoding() for its purpose.
+ Using libpq functions.
+ \encoding actually calls
+ PQsetClientEncoding() for its purpose.
int PQsetClientEncoding(PGconn *conn, const char *encoding);
- where conn is a connection to the server,
- and encoding is the encoding you
- want to use. If the function successfully sets the encoding, it returns 0,
- otherwise -1. The current encoding for this connection can be determined by
- using:
+ where conn is a connection to the server,
+ and encoding is the encoding you
+ want to use. If the function successfully sets the encoding, it returns 0,
+ otherwise -1. The current encoding for this connection can be determined by
+ using:
int PQclientEncoding(const PGconn *conn);
- Note that it returns the encoding ID, not a symbolic string
- such as EUC_JP. To convert an encoding ID to an encoding name, you
- can use:
+ Note that it returns the encoding ID, not a symbolic string
+ such as EUC_JP. To convert an encoding ID to an encoding name, you
+ can use:
char *pg_encoding_to_char(int encoding_id);
@@ -775,27 +801,27 @@ char *pg_encoding_to_char(int encoding_id);
- Using SET client_encoding TO.
+ Using SET client_encoding TO.
- Setting the client encoding can be done with this SQL command:
+ Setting the client encoding can be done with this SQL command:
SET CLIENT_ENCODING TO 'value';
- Also you can use the more standard SQL syntax SET NAMES for this purpose:
+ Also you can use the more standard SQL syntax SET NAMES for this purpose:
SET NAMES 'value';
- To query the current client encoding:
+ To query the current client encoding:
SHOW client_encoding;
- To return to the default encoding:
+ To return to the default encoding:
RESET client_encoding;
@@ -805,7 +831,7 @@ RESET client_encoding;
- Using PGCLIENTENCODING. If environment variable
+ Using PGCLIENTENCODING. If the environment variable
PGCLIENTENCODING is defined in the client's
environment, that client encoding is automatically selected
when a connection to the server is made. (This can
@@ -874,7 +900,7 @@ RESET client_encoding;
- UTF-8 is defined here.
+ UTF-8 is defined here.
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 02db43f049..663cc931be 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1,5 +1,5 @@
@@ -79,7 +79,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 pete
Therefore, database administrators must understand these issues and
develop an appropriate maintenance strategy. This section concentrates
on explaining the high-level issues; for details about command syntax
- and so on, see the VACUUM command reference page.
+ and so on, see the reference page.
@@ -91,6 +91,13 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 pete
times of day.
+
+ Beginning in PostgreSQL 8.0, there are
+ configuration parameters that can be adjusted to further reduce the
+ performance impact of background vacuuming. See
+ .
+
+
Recovering disk space
@@ -162,13 +169,20 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 pete
Recommended practice for most sites is to schedule a database-wide
VACUUM once a day at a low-usage time of day,
supplemented by more frequent vacuuming of heavily-updated tables
- if necessary. In fact, some installations with an extremely high
- rate of data modification VACUUM some tables as
- often as once very five minutes. (If you have multiple databases
+ if necessary. (Some installations with an extremely high
+ rate of data modification VACUUM busy tables as
+ often as once every few minutes.) If you have multiple databases
in a cluster, don't forget to VACUUM each one;
- the program vacuumdb may be helpful.)
+ the program vacuumdb may be helpful.
+
+
+ The contrib/pg_autovacuum program can be useful for
+ automating high-frequency vacuuming operations.
+
+
+
VACUUM FULL is recommended for cases where you know
you have deleted the majority of rows in a table, so that the
@@ -404,6 +418,18 @@ VACUUM
you to ensure that such databases are frozen correctly.
+
+
+ To be sure of safety against transaction wraparound, it is necessary
+ to vacuum every table, including system catalogs, in
+ every database at least once every billion transactions.
+ We have seen data loss situations caused by people deciding that they
+ only needed to vacuum their active user tables, rather than issuing
+ database-wide vacuum commands. That will appear to work fine ...
+ for a while.
+
+
+
@@ -475,7 +501,7 @@ VACUUM
If you start the server with
pg_ctl, then stderr
is already redirected to stdout, so you just need a
- pipe command:
+ pipe command, for example:
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
@@ -499,7 +525,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
On many systems, however, syslog is not very reliable,
particularly with large log messages; it may truncate or drop messages
- just when you need them the most. Also, on linux,
+ just when you need them the most. Also, on Linux,
syslog will sync each message to disk, yielding poor
performance. (You can use a - at the start of the file name
in the syslog configuration file to disable this behavior.)
@@ -508,8 +534,10 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Note that all the solutions described above take care of starting new
log files at configurable intervals, but they do not handle deletion
- of old, no-longer-interesting log files. You will also want to set
- up a batch job to periodically delete old log files.
+ of old, no-longer-interesting log files. You will probably want to set
+ up a batch job to periodically delete old log files. Another possibility
+ is to configure the rotation program so that old log files are overwritten
+ cyclically.
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index c78b8fefb8..0deb3cc8b1 100644
--- a/doc/src/sgml/manage-ag.sgml
+++ b/doc/src/sgml/manage-ag.sgml
@@ -1,5 +1,5 @@
@@ -37,23 +37,21 @@ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.38 2004/12/13 18:05:08 petere
- An application that connects to the database server specifies in
+ When connecting to the database server, a client must specify in
its connection request the name of the database it wants to connect
to. It is not possible to access more than one database per
connection. (But an application is not restricted in the number of
- connections it opens to the same or other databases.) It is
- possible, however, to access more than one schema from the same
- connection. Schemas are a purely logical structure and who can
- access what is managed by the privilege system. Databases are
+ connections it opens to the same or other databases.) 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 databases but possibly
- into separate schemas. More information about managing schemas is
- in .
+ resources they should be put in the same database, but possibly
+ into separate schemas. Schemas are a purely logical structure and who can
+ access what is managed by the privilege system. More information about
+ managing schemas is in .
@@ -116,7 +114,7 @@ CREATE DATABASE name;
- As an extra convenience, there is also a program that you can
+ As a convenience, there is a program that you can
execute from the shell to create new databases,
createdb.createdb
@@ -127,7 +125,7 @@ createdb dbname
createdb does no magic. It connects to the template1
database and issues the CREATE DATABASE command,
exactly as described above.
- The reference page on createdb contains the invocation
+ The reference page contains the invocation
details. Note that createdb without any arguments will create
a database with the current user name, which may or may not be what
you want.
@@ -285,10 +283,11 @@ createdb -T template0 dbname
ALTER DATABASE mydb SET geqo TO off;
- This will save the setting (but not set it immediately) and in
- subsequent connections it will appear as though SET geqo
- TO off; had been called right before the session started.
- Note that users can still alter this setting during the session; it
+ This will save the setting (but not set it immediately). In
+ subsequent connections to this database it will appear as though
+ SET geqo TO off; had been executed just before the
+ session started.
+ Note that users can still alter this setting during their sessions; it
will only be the default. To undo any such setting, use
ALTER DATABASE dbname RESET
varname;.
@@ -322,7 +321,7 @@ DROP DATABASE name;
For convenience, there is also a shell program to drop
- databases:dropdb
+ databases, :dropdb
dropdb dbname
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 0fda608285..c09d2facda 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -1,5 +1,5 @@
@@ -175,9 +175,10 @@ dropuser name
ALTER USER myname SET enable_indexscan TO off;
- This will save the setting (but not set it immediately) and in
- subsequent connections it will appear as though SET enable_indexscan
- TO off; had been called right before the session started.
+ This will save the setting (but not set it immediately). In
+ subsequent connections by this user it will appear as though
+ SET enable_indexscan TO off; had been executed
+ just before the session started.
You can still alter this setting during the session; it will only
be the default. To undo any such setting, use ALTER USER
username RESET varname;.
@@ -243,7 +244,7 @@ ALTER GROUP name DROP USER uname1RULE, REFERENCES, TRIGGER,
CREATE, TEMPORARY, EXECUTE,
USAGE, and ALL PRIVILEGES. For more
- information on the different types of privileges support by
+ information on the different types of privileges supported by
PostgreSQL, see the
reference page.
The right to modify or
@@ -289,18 +290,21 @@ REVOKE ALL ON accounts FROM PUBLIC;
Functions and triggers allow users to insert code into the backend
server that other users may execute without knowing it. Hence, both
mechanisms permit users to Trojan horse
- others with relative impunity. The only real protection is tight
+ others with relative ease. The only real protection is tight
control over who can define functions.
- Functions written in any language except SQL run inside the backend
- server process with the operating systems permissions of the
- database server daemon process. It is possible to change the
- server's internal data structures from inside of trusted functions.
+ Functions run inside the backend
+ server process with the operating system permissions of the
+ database server daemon. If the programmming language
+ used for the function allows unchecked memory accesses, it is
+ possible to change the server's internal data structures.
Hence, among many other things, such functions can circumvent any
- system access controls. This is an inherent problem with
- user-defined C functions.
+ system access controls. Function languages that allow such access
+ are considered untrusted, and
+ PostgreSQL allows only superusers to
+ create functions written in those languages.