This variable specifies the order in which schemas are searched
when an object (table, data type, function, etc.) is referenced by
a simple name with no schema specified. When there are objects of
identical names in different schemas, the one found first in the
search path is used. An object that is not in any of the schemas in
the search path can only be referenced by specifying its containing
schema with a qualified (dotted) name.

The value for search_path must be a
comma-separated list of schema names. Any name that is not an
existing schema, or is a schema for which the user does not have
USAGE permission, is silently ignored.

If one of the list items is the special name $user, then the schema having the name returned by
SESSION_USER is substituted, if there
is such a schema and the user has USAGE
permission for it. (If not, $user is
ignored.)

The system catalog schema, pg_catalog,
is always searched, whether it is mentioned in the path or not. If
it is mentioned in the path then it will be searched in the
specified order. If pg_catalog is not in
the path then it will be searched before searching any of the path
items.

Likewise, the current session's temporary-table schema,
pg_temp_nnn, is always searched if it exists. It
can be explicitly listed in the path by using the alias pg_temp. If it is not listed in the path then it is
searched first (even before pg_catalog).
However, the temporary schema is only searched for relation (table,
view, sequence, etc) and data type names. It is never searched for
function or operator names.

When objects are created without specifying a particular target
schema, they will be placed in the first valid schema named in
search_path. An error is reported if the
search path is empty.

The default value for this parameter is "$user", public. This setting supports shared use of
a database (where no users have private schemas, and all share use
of public), private per-user schemas, and
combinations of these. Other effects can be obtained by altering
the default search path setting, either globally or per-user.

For more information on schema handling, see Section 5.7. In particular, the default
configuration is suitable only when the database has a single user
or a few mutually-trusting users.

The current effective value of the search path can be examined
via the SQL function
current_schemas (see Section 9.25). This is not quite the same
as examining the value of search_path,
since current_schemas shows how the
items appearing in search_path were
resolved.

default_tablespace (string)

This variable specifies the default tablespace in which to
create objects (tables and indexes) when a CREATE command does not explicitly specify a
tablespace.

The value is either the name of a tablespace, or an empty string
to specify using the default tablespace of the current database. If
the value does not match the name of any existing tablespace,
PostgreSQL will automatically use
the default tablespace of the current database. If a nondefault
tablespace is specified, the user must have CREATE privilege for it, or creation attempts will
fail.

This variable is not used for temporary tables; for them,
temp_tablespaces
is consulted instead.

This variable is also not used when creating databases. By
default, a new database inherits its tablespace setting from the
template database it is copied from.

This variable specifies tablespaces in which to create temporary
objects (temp tables and indexes on temp tables) when a CREATE command does not explicitly specify a
tablespace. Temporary files for purposes such as sorting large data
sets are also created in these tablespaces.

The value is a list of names of tablespaces. When there is more
than one name in the list, PostgreSQL chooses a random member of the list
each time a temporary object is to be created; except that within a
transaction, successively created temporary objects are placed in
successive tablespaces from the list. If the selected element of
the list is an empty string, PostgreSQL will automatically use the default
tablespace of the current database instead.

When temp_tablespaces is set
interactively, specifying a nonexistent tablespace is an error, as
is specifying a tablespace for which the user does not have
CREATE privilege. However, when using a
previously set value, nonexistent tablespaces are ignored, as are
tablespaces for which the user lacks CREATE privilege. In particular, this rule applies
when using a value set in postgresql.conf.

The default value is an empty string, which results in all
temporary objects being created in the default tablespace of the
current database.

This parameter is normally on. When set to off, it disables validation of the function body
string during CREATE
FUNCTION. Disabling validation avoids side effects of the
validation process and avoids false positives due to problems such
as forward references. Set this parameter to off before loading functions on behalf of other
users; pg_dump does so
automatically.

default_transaction_isolation (enum)

Each SQL transaction has an isolation level, which can be either
"read uncommitted", "read committed", "repeatable
read", or "serializable". This
parameter controls the default isolation level of each new
transaction. The default is "read
committed".

When running at the serializable
isolation level, a deferrable read-only SQL transaction may be
delayed before it is allowed to proceed. However, once it begins
executing it does not incur any of the overhead required to ensure
serializability; so serialization code will have no reason to force
it to abort because of concurrent updates, making this option
suitable for long-running read-only transactions.

This parameter controls the default deferrable status of each
new transaction. It currently has no effect on read-write
transactions or those operating at isolation levels lower than
serializable. The default is off.

Controls firing of replication-related triggers and rules for
the current session. Setting this variable requires superuser
privilege and results in discarding any previously cached query
plans. Possible values are origin (the
default), replica and local. See ALTER
TABLE for more information.

statement_timeout (integer)

Abort any statement that takes more than the specified number of
milliseconds, starting from the time the command arrives at the
server from the client. If log_min_error_statement is set to ERROR or lower, the statement that timed out will
also be logged. A value of zero (the default) turns this off.

Setting statement_timeout in postgresql.conf is not recommended because it would
affect all sessions.

lock_timeout (integer)

Abort any statement that waits longer than the specified number
of milliseconds while attempting to acquire a lock on a table,
index, row, or other database object. The time limit applies
separately to each lock acquisition attempt. The limit applies both
to explicit locking requests (such as LOCK
TABLE, or SELECT FOR UPDATE without
NOWAIT) and to implicitly-acquired locks.
If log_min_error_statement is set to
ERROR or lower, the statement that timed
out will be logged. A value of zero (the default) turns this
off.

Unlike statement_timeout, this timeout
can only occur while waiting for locks. Note that if statement_timeout is nonzero, it is rather pointless
to set lock_timeout to the same or larger
value, since the statement timeout would always trigger first.

Setting lock_timeout in postgresql.conf is not recommended because it would
affect all sessions.

vacuum_freeze_table_age (integer)

VACUUM performs a whole-table scan if
the table's pg_class.relfrozenxid field has reached the age specified
by this setting. The default is 150 million transactions. Although
users can set this value anywhere from zero to two billions,
VACUUM will silently limit the effective
value to 95% of autovacuum_freeze_max_age,
so that a periodical manual VACUUM has a
chance to run before an anti-wraparound autovacuum is launched for
the table. For more information see Section
23.1.5.

vacuum_freeze_min_age (integer)

Specifies the cutoff age (in transactions) that VACUUM should use to decide whether to replace
transaction IDs with FrozenXID while
scanning a table. The default is 50 million transactions. Although
users can set this value anywhere from zero to one billion,
VACUUM will silently limit the effective
value to half the value of autovacuum_freeze_max_age,
so that there is not an unreasonably short time between forced
autovacuums. For more information see Section
23.1.5.

vacuum_multixact_freeze_table_age (integer)

VACUUM performs a whole-table scan if
the table's pg_class.relminmxid field has reached the age specified
by this setting. The default is 150 million multixacts. Although
users can set this value anywhere from zero to two billions,
VACUUM will silently limit the effective
value to 95% of
autovacuum_multixact_freeze_max_age, so that a periodical
manual VACUUM has a chance to run before
an anti-wraparound is launched for the table. For more information
see Section
23.1.5.1.

vacuum_multixact_freeze_min_age (integer)

Specifies the cutoff age (in multixacts) that VACUUM should use to decide whether to replace
multixact IDs with a newer transaction ID or multixact ID while
scanning a table. The default is 5 million multixacts. Although
users can set this value anywhere from zero to one billion,
VACUUM will silently limit the effective
value to half the value of
autovacuum_multixact_freeze_max_age, so that there is not an
unreasonably short time between forced autovacuums. For more
information see Section
23.1.5.1.

bytea_output (enum)

Sets the output format for values of type bytea. Valid values are hex
(the default) and escape (the traditional
PostgreSQL format). See Section
8.4 for more information. The bytea type
always accepts both formats on input, regardless of this
setting.

xmlbinary (enum)

Sets how binary values are to be encoded in XML. This applies
for example when bytea values are converted
to XML by the functions xmlelement or
xmlforest. Possible values are
base64 and hex,
which are both defined in the XML Schema standard. The default is
base64. For further information about
XML-related functions, see Section
9.14.

The actual choice here is mostly a matter of taste, constrained
only by possible restrictions in client applications. Both methods
support all possible values, although the hex encoding will be
somewhat larger than the base64 encoding.

xmloption (enum)

Sets whether DOCUMENT or CONTENT is implicit when converting between XML and
character string values. See Section
8.13 for a description of this. Valid values are DOCUMENT and CONTENT. The
default is CONTENT.

Sets the display format for date and time values, as well as the
rules for interpreting ambiguous date input values. For historical
reasons, this variable contains two independent components: the
output format specification (ISO,
Postgres, SQL, or
German) and the input/output specification
for year/month/day ordering (DMY,
MDY, or YMD).
These can be set separately or together. The keywords Euro and European are
synonyms for DMY; the keywords US, NonEuro, and NonEuropean are synonyms for MDY. See Section
8.5 for more information. The built-in default is ISO, MDY, but initdb will initialize the configuration file
with a setting that corresponds to the behavior of the chosen
lc_time locale.

IntervalStyle
(enum)

Sets the display format for interval values. The value
sql_standard will produce output matching
SQL standard interval literals.
The value postgres (which is the default)
will produce output matching PostgreSQL releases prior to 8.4 when the
DateStyle
parameter was set to ISO. The value
postgres_verbose will produce output
matching PostgreSQL releases prior
to 8.4 when the DateStyle parameter was
set to non-ISO output. The value
iso_8601 will produce output matching the
time interval "format with designators"
defined in section 4.4.3.2 of ISO 8601.

The IntervalStyle parameter also
affects the interpretation of ambiguous interval input. See
Section
8.5.4 for more information.

TimeZone (string)

Sets the time zone for displaying and interpreting time stamps.
The built-in default is GMT, but that is
typically overridden in postgresql.conf;
initdb will install a setting
there corresponding to its system environment. See Section 8.5.3 for
more information.

timezone_abbreviations (string)

Sets the collection of time zone abbreviations that will be
accepted by the server for datetime input. The default is
'Default', which is a collection that
works in most of the world; there are also 'Australia' and 'India',
and other collections can be defined for a particular installation.
See Section B.3 for more
information.

extra_float_digits (integer)

This parameter adjusts the number of digits displayed for
floating-point values, including float4,
float8, and geometric data types. The
parameter value is added to the standard number of digits
(FLT_DIG or DBL_DIG as appropriate). The value can be set as
high as 3, to include partially-significant digits; this is
especially useful for dumping float data that needs to be restored
exactly. Or it can be set negative to suppress unwanted digits. See
also Section
8.1.3.

client_encoding
(string)

Sets the client-side encoding (character set). The default is to
use the database encoding. The character sets supported by the
PostgreSQL server are described in
Section
22.3.1.

lc_messages (string)

Sets the language in which messages are displayed. Acceptable
values are system-dependent; see Section
22.1 for more information. If this variable is set to the empty
string (which is the default) then the value is inherited from the
execution environment of the server in a system-dependent way.

On some systems, this locale category does not exist. Setting
this variable will still work, but there will be no effect. Also,
there is a chance that no translated messages for the desired
language exist. In that case you will continue to see the English
messages.

Only superusers can change this setting, because it affects the
messages sent to the server log as well as to the client, and an
improper value might obscure the readability of the server
logs.

lc_monetary (string)

Sets the locale to use for formatting monetary amounts, for
example with the to_char family of
functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this
variable is set to the empty string (which is the default) then the
value is inherited from the execution environment of the server in
a system-dependent way.

lc_numeric (string)

Sets the locale to use for formatting numbers, for example with
the to_char family of functions.
Acceptable values are system-dependent; see Section 22.1 for more information. If this
variable is set to the empty string (which is the default) then the
value is inherited from the execution environment of the server in
a system-dependent way.

lc_time (string)

Sets the locale to use for formatting dates and times, for
example with the to_char family of
functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this
variable is set to the empty string (which is the default) then the
value is inherited from the execution environment of the server in
a system-dependent way.

default_text_search_config (string)

Selects the text search configuration that is used by those
variants of the text search functions that do not have an explicit
argument specifying the configuration. See Chapter 12 for further information. The
built-in default is pg_catalog.simple, but
initdb will initialize the
configuration file with a setting that corresponds to the chosen
lc_ctype locale, if a configuration
matching that locale can be identified.

If a dynamically loadable module needs to be opened and the file
name specified in the CREATE FUNCTION or
LOAD command does not have a directory
component (i.e., the name does not contain a slash), the system
will search this path for the required file.

The value for dynamic_library_path must
be a list of absolute directory paths separated by colons (or
semi-colons on Windows). If a list element starts with the special
string $libdir, the compiled-in
PostgreSQL package library
directory is substituted for $libdir; this
is where the modules provided by the standard PostgreSQL distribution are installed. (Use
pg_config --pkglibdir to find out the name
of this directory.) For example:

The default value for this parameter is '$libdir'. If the value is set to an empty string,
the automatic path search is turned off.

This parameter can be changed at run time by superusers, but a
setting done that way will only persist until the end of the client
connection, so this method should be reserved for development
purposes. The recommended way to set this parameter is in the
postgresql.conf configuration file.

gin_fuzzy_search_limit (integer)

Soft upper limit of the size of the set returned by GIN index
scans. For more information see Section
57.4.

local_preload_libraries (string)

This variable specifies one or more shared libraries that are to
be preloaded at connection start. If more than one library is to be
loaded, separate their names with commas. All library names are
converted to lower case unless double-quoted. This parameter cannot
be changed after the start of a particular session.

Because this is not a superuser-only option, the libraries that
can be loaded are restricted to those appearing in the plugins subdirectory of the installation's standard
library directory. (It is the database administrator's
responsibility to ensure that only "safe" libraries are installed there.) Entries in
local_preload_libraries can specify this
directory explicitly, for example $libdir/plugins/mylib, or just specify the library
name — mylib would have the same effect as
$libdir/plugins/mylib.

Unlike shared_preload_libraries,
there is no performance advantage to loading a library at session
start rather than when it is first used. Rather, the intent of this
feature is to allow debugging or performance-measurement libraries
to be loaded into specific sessions without an explicit LOAD command being given. For example, debugging
could be enabled for a session by setting this parameter via the
PGOPTIONS environment variable.

If a specified library is not found, the connection attempt will
fail.

Every PostgreSQL-supported library has a "magic block" that is checked to guarantee
compatibility. For this reason, non-PostgreSQL libraries cannot be
loaded in this way.