pg_settings Columns
- 4>
+ 3>
|
Name
Type
- References
Description
|
- name
+ name
text
-
The name of a current session run-time parameter
|
- setting
+ setting
text
-
The value of a current session run-time parameter
Sets the optimizer's estimate of the cost of processing each
- operator in a WHERE clause. This is measured as a fraction of
+ operator in a WHERE> clause. This is measured as a fraction of
the cost of a sequential page fetch.
SERVER_MIN_MESSAGES (string)
- This controls how much detail is written to the server logs. The
- default is NOTICE>. Valid values are DEBUG5>,
+ This controls how much message detail is written to the server
+ logs. Valid values are DEBUG5>,
DEBUG4>, DEBUG3>, DEBUG2>,
DEBUG1>, INFO>, NOTICE>,
- WARNING>, ERROR>, LOG>,
- FATAL>, and PANIC>. Later values send less
- detail to the logs. LOG> has a different precedence
- here than in CLIENT_MIN_MESSAGES>.
+ WARNING>, ERROR>, LOG>,
+ FATAL>, and PANIC>. Later values send
+ less detail to the logs. The default is NOTICE>.
+ Note that LOG> has a different precedence here than
+ in CLIENT_MIN_MESSAGES>.
+
Here is a summary of the various message types:
- <varname>DEBUG[1-5]>
+ <literal>DEBUG[1-5]>
- This provides information for use by developers.
+ Provides information for use by developers.
+
- <varname>INFO>
+ <literal>INFO>
- This provides information requested by the user, e.g.
- SET>.
+ Provides information implicitly requested by the user,
+ e.g., during VACUUM VERBOSE>.
+
- <varname>NOTICE>
+ <literal>NOTICE>
- This provides information that may be helpful to users, e.g.
- truncation of long identifiers, sequence creation as part of
- SERIAL>.
+ Provides information that may be helpful to users, e.g.,
+ truncation of long identifiers and index creation as part
+ of primary keys.
+
- <varname>WARNING>
+ <literal>WARNING>
- This provides warnings to the user, e.g. COMMIT>
+ Provides warnings to the user, e.g., COMMIT>
outside a transaction.
+
- <varname>ERROR>
+ <literal>ERROR>
- Reports the error that caused the transaction to abort.
+ Reports the error that caused a transaction to abort.
- <varname>LOG>
+ <literal>LOG>
- This reports information of interest to administrators, e.g.
+ Reports information of interest to administrators, e.g.,
checkpoint activity.
+
- <varname>FATAL>
+ <literal>FATAL>
- This reports why the backend session terminated.
+ Reports why a backend session terminated.
+
- <varname>PANIC>
+ <literal>PANIC>
- This reports why all backends restarted.
+ Reports why all backend sessions restarted.
CLIENT_MIN_MESSAGES (string)
- This controls how much detail is written to the client. The
- default is NOTICE>. Valid values are
- DEBUG5>, DEBUG4>, DEBUG3>,
- DEBUG2>, DEBUG1>, LOG>,
- NOTICE>, WARNING>, and ERROR>.
- Later values send less information to the user. LOG>
- has a different precedence here than in
- SERVER_MIN_MESSAGES>. Also see that section for an
- explanation of the various values.
+ This controls how much message detail is written to the
+ client. Valid values are DEBUG5>,
+ DEBUG4>, DEBUG3>, DEBUG2>,
+ DEBUG1>, LOG>, NOTICE>,
+ WARNING>, and ERROR>. Later values send
+ less information to the client. The default is
+ NOTICE>. Note that LOG> has a different
+ precedence here than in SERVER_MIN_MESSAGES>. Also
+ see that section for an explanation of the various values.
to turn this on, as it might expose programming mistakes. To use
this option, the macro USE_ASSERT_CHECKING
must be defined when
PostgreSQL is
- built (accomplished by the configure option
+ built (accomplished by the configure option
). Note that
DEBUG_ASSERTIONS defaults to on if
PostgreSQL has been built with
These flags enable various debugging output to be sent to the
- server log. For each executed query, prints either the query text,
+ server log. For each executed query, print either the query text,
the resulting parse tree, the query rewriter output, or the execution
plan. indents these displays
to produce a more readable but much longer output format.
+
+ LOG_DURATION (boolean)
+
+ Causes the duration of every completed statement to be logged.
+ To use this option, enable LOG_STATEMENT> and
+ LOG_PID> so you can link the statement to the
+ duration using the process ID.
+
+
+
+
LOG_MIN_ERROR_STATEMENT (string)
- This controls which message types output the original query to
- the server logs. All queries matching the setting or higher are
- logged. The default is PANIC (effectively
- "off"). Valid values are DEBUG5,
- DEBUG4, DEBUG3,
- DEBUG2, DEBUG1,
- INFO, NOTICE,
- WARNING, ERROR,
- FATAL, and PANIC.
+ This controls for which message levels the SQL statement
+ causing that message is to be recorded in the server log. All
+ statements causing a message of the level of the setting or
+ higher are logged. The default is PANIC
+ (effectively turning this feature off). Valid values are
+ DEBUG5, DEBUG4,
+ DEBUG3, DEBUG2,
+ DEBUG1, INFO,
+ NOTICE, WARNING,
+ ERROR, FATAL, and
+ PANIC. For example, if you set this to
+ ERROR then all SQL statements causing
+ errors, fatal errors, or panics will be logged.
+
- It is recommended you enable <literal>LOG_PID> as well
+ It is recommended you enable <varname>LOG_PID> as well
so you can more easily match the error statement with the error
message.
LOG_STATEMENT (boolean)
- Prints each query received.
-
-
-
-
-
- LOG_DURATION (boolean)
-
- Prints the duration of every completed query. To use this option,
- enable LOG_STATEMENT> and LOG_PID> so you
- can link the original query to the duration using the process id.
+ Causes each SQL statement to be logged.
This option determines the
syslog
facility
to be used when
syslog is enabled. You may choose
- from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6,
- LOCAL7; the default is LOCAL0. See also the documentation of
+ from LOCAL0>, LOCAL1>,
+ LOCAL2>, LOCAL3>, LOCAL4>,
+ LOCAL5>, LOCAL6>, LOCAL7>;
+ the default is LOCAL0>. See also the
+ documentation of your system's
-
General operation
+
General Operation
- AUTOCOMMIT (bool)
+ AUTOCOMMIT (boolean)
Once another command is issued, a transaction block
begins and any SET>, SHOW>, or
RESET> commands are considered to be part of the
- transaction, i.e. they are committed or rolled back depending
+ transaction, i.e., they are committed or rolled back depending
on the completion status of the transaction. To execute a
SET>, SHOW>, or RESET>
command at the start of a transaction block, use BEGIN>
- AUSTRALIAN_TIMEZONES (bool)
+ AUSTRALIAN_TIMEZONES (boolean)
DB_USER_NAMESPACE (boolean)
- This allows per-database user names. You can create users as
- username@dbname>. When username> is passed by the client,
- @> and the database name is appended to the user name and
- that database-specific user name is looked up by the server.
- When creating user names containing @>, you will need
- to quote the user name.
+ This allows per-database user names. It is off by default.
+
+
+ If this is on, create users as username@dbname>.
+ When username> is passed by a connecting client,
+ @> and the database name is appended to the user
+ name and that database-specific user name is looked up by the
+ server. Note that when you create users with names containing
+ @> within the SQL environment, you will need to
+ quote the user name.
+
- With this option enabled, you can still create ordinary global
- users. Simply append @> when specifying the user name
- in the client. The @> will be stripped off and looked up
- by the server.
+ With this option enabled, you can still create ordinary global
+ users. Simply append @> when specifying the user
+ name in the client. The @> will be stripped off
+ before the user name is looked up by the server.
+
+
+ This feature is intended as a temporary measure until a
+ complete solution is found. At that time, this option will
+ be removed.
+
+
- Consult the PostgreSQL User's Guide and
+ Consult the &cite-user; and
the command SET TRANSACTION for more
information.
distribution are installed. (Use pg_config
--pkglibdir to print the name of this directory.) For
example:
-
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
-
When a password is specified in CREATE USER> or
- ALTER USER> without writing either ENCRYPTED or
- UNENCRYPTED, this flag determines whether the password is to be
+ ALTER USER> without writing either ENCRYPTED> or
+ UNENCRYPTED>, this flag determines whether the password is to be
encrypted. The default is on (encrypt the password).
- This variable specifies the order in which namespaces are searched
- when an object (table, data type, function, etc) is referenced by a
+ 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 component. When there are objects of
- identical names in different namespaces, the one found first
+ identical names in different schemas, the one found first
in the search path is used. An object that is not in any of the
- namespaces in the search path can only be referenced by specifying
- its containing namespace with a qualified (dotted) name.
+ schemas in the search path can only be referenced by specifying
+ its containing schema with a qualified (dotted) name.
- The value for search_path has to be a comma-separated
- list of namespace (schema) names. If one of the list items is
- the special value $user, then the namespace
- having the same name as the SESSION_USER is substituted, if there
- is such a namespace. (If not, $user is ignored.)
+ The value for search_path has to be a comma-separated
+ list of schema names. If one of the list items is
+ the special value $user, then the schema
+ having the same name as the SESSION_USER> is substituted, if there
+ is such a schema. (If not, $user is ignored.)
- The system catalog namespace, pg_catalog>, is always
+ 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.
- It should also be noted that the temporary-table namespace,
- pg_temp_nnn>, is implicitly searched before any of
+ It should also be noted that the temporary-table schema,
+ pg_temp_nnn>>, is implicitly searched before any of
these.
When objects are created without specifying a particular target
- namespace, they will be placed in the first namespace listed
+ schema, they will be placed in the first schema listed
in the search path. An error is reported if the search path is
empty.
The default value for this parameter is
'$user, public' (where the second part will be
- ignored if there is no namespace named public>).
+ ignored if there is no schema named public>).
This supports shared use of a database (where no users
- have private namespaces, and all share use of public>),
- private per-user namespaces, and combinations of these. Other
+ 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.
- By default, a newly created database will contain a world-writable
- namespace named public>, but no private namespaces.
- The administrator may choose to restrict permissions on
- public> or even remove it, if that suits his purposes.
-
-
shows how the requests appearing in search_path
were resolved.
+
+ For more information on schema handling, see the &cite-user;.
+
SILENT_MODE (bool)
- Runs postmaster silently. If this option is set, the postmaster
+ Runs the server silently. If this option is set, the server
will automatically run in background and any controlling ttys
are disassociated, thus no messages are written to standard
- output or standard error (same effect as postmaster's -S
+ output or standard error (same effect as postmaster>'s
option). Unless some logging system such as
syslog> is enabled, using this option is
discouraged since it makes it impossible to see error messages.
Specifies the amount of memory to be used by internal sorts and
hashes before switching to temporary disk files. The value is
- specified in kilobytes, and defaults to 1024 kilobytes (1MB).
+ specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
Note that for a complex query, several sorts might be running in
parallel, and each one will be allowed to use as much memory as
this value specifies before it starts to put data into temporary
files. Also, each running backend could be doing one or more
sorts simultaneously, so the total memory used could be many
times the value of SORT_MEM. Sorts are used
- by ORDER BY, merge joins, and CREATE INDEX.
+ by ORDER BY>, merge joins, and CREATE INDEX>.
behavior you can set this variable to off, but in the long run
you are encouraged to change your applications to use the
ONLY keyword to exclude subtables. See the
- SQL language reference and the User's
- Guide for more information about inheritance.
+ SQL language reference and the &cite-user; for more information about inheritance.
Sets the time zone for displaying and interpreting timestamps.
The default is to use whatever the system environment
- specifies as the timezone.
+ specifies as the time zone.
expr> = NULL (or NULL
= expr>) are treated as
expr> IS NULL, that is, they
- return true if expr> evaluates to the NULL value,
+ return true if expr> evaluates to the null value,
and false otherwise. The correct behavior of
expr> = NULL is to always
- return NULL (unknown). Therefore this option defaults to off.
+ return null (unknown). Therefore this option defaults to off.
null values, so if you use that interface to access the database you
might want to turn this option on. Since expressions of the
form expr> = NULL always
- return NULL (using the correct interpretation) they are not
+ return the null value (using the correct interpretation) they are not
very useful and do not appear often in normal applications, so
this option does little harm in practice. But new users are
frequently confused about the semantics of expressions
- involving NULL, so this option is not on by default.
+ involving null values, so this option is not on by default.
- Refer to the User's Guide for related
- information.
+ Refer to the &cite-user; for related information.
Specifies the directory of the Unix-domain socket on which the
-
postmaster is to listen for
+ server is to listen for
connections from client applications. The default is normally
/tmp, but can be changed at build time.
Sets the group owner of the Unix domain socket. (The owning
user of the socket is always the user that starts the
- postmaster.) In combination with the option
+ server.) In combination with the option
this can be used as
an additional access control mechanism for this socket type.
By default this is the empty string, which uses the default
anyone can connect. Reasonable alternatives are
0770 (only user and group, see also under
) and 0700
- (only user). (Note that actually for a Unix socket, only write
+ (only user). (Note that actually for a Unix domain socket, only write
permission matters and there is no point in setting or revoking
read or execute permissions.)
enough additional transactions may become ready to commit within
the given interval. But the delay is just wasted if no other
transactions become ready to commit. Therefore, the delay is
- only performed if at least COMMIT_SIBLINGS other transactions
- are active at the instant that a backend has written its commit
+ only performed if at least COMMIT_SIBLINGS other transactions
+ are active at the instant that a backend process has written its commit
record.
WAL_DEBUG (integer)
- If non-zero, turn on WAL-related debugging output on standard
+ If nonzero, turn on WAL-related debugging output on standard
error.
-
-
Short options
+
+
Short Options
+
For convenience there are also single letter option switches
- available for many parameters. They are described in the following
- table.
+ available for many parameters. They are described in
+ linkend="runtime-config-short-table">.
+
-
+
id="runtime-config-short-table">
Short option key
-
-
+
|
Short option
Equivalent
- Remark
+
|
shared_buffers = x>
-
|
- server_min_messages = DEBUGx>
-
+ server_min_messages = DEBUGx>
|
fsync = off>
-
|
virtual_host = x>
-
|
tcpip_socket = on>
-
|
unix_socket_directory = x>
-
|
ssl = on>
-
|
max_connections = x>
-
|
port = x>
-
|
- , , , , ,
- enable_indexscan=off>, enable_hashjoin=off>,
- enable_mergejoin=off>, enable_nestloop=off>, enable_seqscan=off>,
- enable_tidscan=off>
- *
+
+ , ,
+ , ,
+
,
+ id="fn.runtime-config-short">
+ For historical reasons, these options must be passed to
+ the individual backend process via the
+ postmaster option, for example,
+
+$ postmaster -o '-S 1024 -s'
+
+ or via PGOPTIONS from the client side, as
+ explained above.
+
+
+
+
+ enable_indexscan=off>,
+ enable_hashjoin=off>,
+ enable_mergejoin=off>,
+ enable_nestloop=off>,
+ enable_seqscan=off>,
+ enable_tidscan=off>
+
+
|
-
- sort_mem = x>
- *
+
+ show_statement_stats = on>
+
|
- >
- <entry>show_statement_stats = on></entry>
- *
+ >
+
+ sort_mem = x>
+
|
- , ,
+ , , <footnoteref linkend="fn.runtime-config-short"></entry>
show_parser_stats=on>, show_planner_stats=on>, show_executor_stats=on>
- *
- For historical reasons, options marked *
must be
- passed to the individual backend process via the
- postmaster option, for example,
-
-$ postmaster -o '-S 1024 -s'
-
- or via PGOPTIONS from the client side, as explained
- above.
-
-
+
|
SHMMAX>>
Maximum size of shared memory segment (bytes)>
- 250kB + 8.2kB * shared_buffers> + 14.2kB * max_connections> or infinity
+ 250kB + 8.2 kB * shared_buffers> + 14.2 kB * max_connections> or infinity
|
mind that shared memory is not pageable; it is locked in RAM.
To increase the number of shared buffers supported by the
postmaster, add the following to your kernel configuration
- file. A SHMALL> value of 1024 represents 4MB of
+ file. A SHMALL> value of 1024 represents 4 MB of
shared memory. The following increases the maximum shared
memory area to 32 MB:
For those running 4.1 or later, just make the above changes,
recompile the kernel, and reboot. For those running earlier
- releases, use <application>bpatch> to find the
+ releases, use <command>bpatch> to find the
sysptsize> value in the current kernel. This is
computed dynamically at boot time.
-
Shutting down the server
+
Shutting Down the Server
There are several ways to shut down the database server. You control
With SSL support compiled in, the
PostgreSQL> server
- can be started with the argument
- SSL connections. When starting in SSL mode, the server will look
- for the files server.key> and server.crt> in
- the data directory. These files should contain the server private key
- and certificate respectively. These files must be set up correctly
- before an SSL-enabled server can start. If the private key is protected
- with a passphrase, the server will prompt for the passphrase and will
- not start until it has been entered.
+ can be started with SSL support by setting the parameter
+ ssl to on in
+ postgresql.conf. When starting in SSL mode,
+ the server will look for the files server.key> and
+ server.crt> in the data directory. These files should
+ contain the server private key and certificate respectively. These
+ files must be set up correctly before an SSL-enabled server can
+ start. If the private key is protected with a passphrase, the
+ server will prompt for the passphrase and will not start until it
+ has been entered.
For details on how to create your server private key and certificate,
refer to the
OpenSSL> documentation. A simple
self-signed certificate can be used to get started for testing, but a
- certificate signed by a
CA> (either one of the global
+ certificate signed by a
certificate authority (CA>) (either one of the global
CAs> or a local one) should be used in production so the
client can verify the server's identity. To create a quick
self-signed certificate, use the following
-cd $PGDATA
openssl req -new -text -out server.req
Fill out the information that openssl> asks for. Make sure
that you enter the local host name as Common Name; the challenge
password can be left blank. The script will generate a key that is
- passphrase protected; it will not accept a pass phrase that is less
+ passphrase protected; it will not accept a passphrase that is less
than four characters long. To remove the passphrase (as you must if
you want automatic start-up of the server), run the commands
-
Secure TCP/IP Connections with SSH tunnels
+
Secure TCP/IP Connections with SSH Tunnels
- One can use <productname>ssh> to encrypt the network
+ One can use <application>SSH> to encrypt the network
connection between clients and a
PostgreSQL server. Done properly, this
- should lead to an adequately secure network connection.
+ provides an adequately secure network connection.
- First make sure that an
ssh server is
+ First make sure that an
SSH server is
running properly on the same machine as
PostgreSQL and that you can log in using
ssh as some user. Then you can establish a secure
tunnel with a command like this from the client machine:
The first number in the argument, 3333, is the
port number of your end of the tunnel; it can be chosen freely. The
- Several other products exist that can provide secure tunnels using
+ Several other applications exist that can provide secure tunnels using
a procedure similar in concept to the one just described.
Using an existing graphical frontend tool like
-
ODBC) to create and manipulate a database.
- These possibilities are not covered in this tutorial.
+
PgAccess or
an office suite with
+ database. These possibilities are not covered in this
+ tutorial.
characters of an identifier; longer names can be written in
commands, but they will be truncated. By default,
NAMEDATALEN is 64 so the maximum identifier length
- is 63 (but at the time the system is built,
+ is 63 (but at the time PostgreSQL is built,
NAMEDATALEN can be changed in
src/include/postgres_ext.h).
Quoted identifiers can contain any character other than a double
- quote itself. This allows constructing table or column names that
- would otherwise not be possible, such as ones containing spaces or
+ quote itself. To include a double quote, write two double quotes.
+ This allows constructing table or column names that would
+ otherwise not be possible, such as ones containing spaces or
ampersands. The length limitation still applies.
SELECT 'foo' 'bar';
is not valid syntax. (This slightly bizarre behavior is specified
- by
SQL9x;
PostgreSQL is
following the standard.)
Alternatively, bit-string constants can be specified in hexadecimal
notation, using a leading X (upper or lower case),
e.g., X'1FF'. This notation is equivalent to
- a bit-string constant with four binary digits for each hex digit.
+ a bit-string constant with four binary digits for each hexadecimal digit.
decimal point, if one is used. At least one digit must follow the
exponent marker (e), if one is present.
There may not be any spaces or other characters embedded in the
- constant. Notice that any leading plus or minus sign is not actually
+ constant. Note that any leading plus or minus sign is not actually
considered part of the constant; it is an operator applied to the
constant.
- The precedence and associativity of the operators is hard-wired
- into the parser. Most operators have the same precedence and are
- left-associative. This may lead to non-intuitive behavior; for
- example the Boolean operators <> and >> have a different
- precedence than the Boolean operators <=> and >=>. Also,
- you will sometimes need to add parentheses when using combinations
- of binary and unary operators. For instance
+ shows the precedence and
+ associativity of the operators in PostgreSQL. Most operators have
+ the same precedence and are left-associative. The precedence and
+ associativity of the operators is hard-wired into the parser.
+ This may lead to non-intuitive behavior; for example the Boolean
+ operators <> and >> have a different
+ precedence than the Boolean operators <=> and
+ >=>. Also, you will sometimes need to add
+ parentheses when using combinations of binary and unary operators.
+ For instance
SELECT 5 ! - 6;
This is the price one pays for extensibility.
-
tocentry="1">
+
id="sql-precedence-table">
Operator Precedence (decreasing)
SELECT 3 OPERATOR(pg_catalog.+) 4;
the OPERATOR> construct is taken to have the default precedence
- shown above for any other> operator. This is true no matter
+ shown in for any other> operator. This is true no matter
which specific operator name appears inside OPERATOR()>.
-( expression )
- Parentheses are used to group subexpressions and override precedence.
+ Another value expression in parentheses, useful to group subexpressions and override precedence.
Column References
- A column can be referenced in the form:
+ A column can be referenced in the form
-correlation.columnname `['subscript`]'
+correlation.columnname
+ or
+
+correlation.columnname[subscript]
+
+ (Here, the brackets [ ] are meant to appear literally.)
+
correlation is the name of a
table (possibly qualified), or an alias for a table defined by means of a
- FROM clause, or
+ FROM clause, or
the key words NEW or OLD.
- (NEW and OLD can only appear in rules,
+ (NEW and OLD can only appear in rewrite rules,
while other correlation names can be used in any SQL statement.)
The correlation name and separating dot may be omitted if the column name
- is unique
- across all the tables being used in the current query. If
- column is of an array type, then the
+ is unique across all the tables being used in the current query. (See also .)
+
+
+ If column is of an array type, then the
optional subscript selects a specific
element or elements in the array. If no subscript is provided, then the
whole array is selected. (See for more about
dept, as
-CREATE FUNCTION dept (text) RETURNS dept
- AS 'SELECT * FROM dept WHERE name = $1'
- LANGUAGE SQL;
+CREATE FUNCTION dept(text) RETURNS dept
+ AS 'SELECT * FROM dept WHERE name = $1'
+ LANGUAGE SQL;
Here the $1 will be replaced by the first
keywords AND, OR, and
NOT, or is a qualified operator name
- OPERATOR(>schema>.>operatorname>)>
+OPERATOR(>schema>.>operatorname>)>
Which particular operators exist and whether
they are unary or binary depends on what operators have been
output value, such as the sum or average of the inputs. The
syntax of an aggregate expression is one of the following:
- >
- aggregate_name (expression)
- aggregate_name (ALL expression)
- aggregate_name (DISTINCT expression)
- aggregate_name ( * )
- >
+>
+aggregate_name (expression)
+aggregate_name (ALL expression)
+aggregate_name (DISTINCT expression)
+aggregate_name ( * )
+>
where aggregate_name is a previously
defined aggregate (possibly a qualified name), and
CAST ( expression AS type )
expression::type
- The CAST> syntax conforms to SQL92; the syntax with
+ The CAST> syntax conforms to SQL; the syntax with
:: is historical
PostgreSQL
usage.
to the type that a value expression must produce (for example, when it is
assigned to a table column); the system will automatically apply a
type cast in such cases. However, automatic casting is only done for
- cast functions that are marked OK to apply implicitly>
- in the system catalogs. Other cast functions must be invoked with
+ casts that are marked OK to apply implicitly>
+ in the system catalogs. Other casts must be invoked with
explicit casting syntax. This restriction is intended to prevent
surprising conversions from being applied silently.
double-quoted, because of syntactic conflicts. Therefore, the use of
the function-like cast syntax leads to inconsistencies and should
probably be avoided in new applications.
+
+ (The function-like syntax is in fact just a function call. When
+ one of the two standard cast syntaxes is used to do a run-time
+ conversion, it will internally invoke a registered function to
+ perform the conversion. By convention, these conversion functions
+ have the same name as their output type, but this is not something
+ that a portable application should rely on.)
A scalar subquery is an ordinary
- SELECT in parentheses that returns exactly one
- row with one column. The SELECT query is executed
+ SELECT query in parentheses that returns exactly one
+ row with one column. (See for information about writing queries.)
+ The SELECT query is executed
and the single returned value is used in the surrounding value expression.
It is an error to use a query that
returns more than one row or more than one column as a scalar subquery.
state:
SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
-FROM states;
+ FROM states;
As a consequence, it is unwise to use functions with side effects
as part of complex expressions. It is particularly dangerous to
- rely on side effects or evaluation order in WHERE and HAVING clauses,
+ rely on side effects or evaluation order in WHERE> and HAVING> clauses,
since those clauses are extensively reprocessed as part of
developing an execution plan. Boolean
- expressions (AND/OR/NOT combinations) in those clauses may be reorganized
+ expressions (AND>/OR>/NOT> combinations) in those clauses may be reorganized
in any manner allowed by the laws of Boolean algebra.
- When it is essential to force evaluation order, a CASE construct may
- be used. For example, this is an untrustworthy way of trying to
- avoid division by zero in a WHERE clause:
+ When it is essential to force evaluation order, a CASE>
+ construct (see ) may be
+ used. For example, this is an untrustworthy way of trying to
+ avoid division by zero in a WHERE> clause:
SELECT ... WHERE x <> 0 AND y/x > 1.5;
- but this is safe:
+ But this is safe:
SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 1.5 ELSE false END;
- A CASE construct used in this fashion will defeat optimization attempts,
+ A CASE> construct used in this fashion will defeat optimization attempts,
so it should only be done when necessary.
Type Conversion
-
-
Introduction
-
SQL queries can, intentionally or not, require
mixing of different data types in the same expression.
-The Programmer's Guide has more details on the exact algorithms used for
+The &cite-programmer; has more details on the exact algorithms used for
implicit type conversion and coercion.
-
Overview
SQL is a strongly typed language. That is, every data item
has an associated data type which determines its behavior and allowed usage.
PostgreSQL has an extensible type system that is
-much more general and flexible than other
RDBMS implementations.
+much more general and flexible than other
SQL implementations.
Hence, most type conversion behavior in
PostgreSQL
should be governed by general rules rather than by ad hoc> heuristics, to allow
mixed-type expressions to be meaningful even with user-defined types.
-The
PostgreSQL parser uses the convention that all
-type conversion functions take a single argument of the source type and are
-named with the same name as the target type. Any function meeting these
-criteria is considered to be a valid conversion function, and may be used
-by the parser as such. This simple assumption gives the parser the power
-to explore type conversion possibilities without hardcoding, allowing
-extended user-defined types to use these same features transparently.
+The system catalogs store information about which conversions, called
+casts, between data types are valid, and how to
+perform those conversions. Additional casts can be added by the user
+with the CREATE CAST command. (This is usually
+done in conjunction with defining new data types. The set of casts
+between the built-in types has been carefully crafted and should not
+be altered.)
All type conversion rules are designed with several principles in mind:
- mark="bullet" spacing="compact">
+
Implicit conversions should never have surprising or unpredictable outcomes.
A password is only significant if the client authentication
method requires the user to supply a password when connecting
- to the database. At present, the
+ to the database. The
make use of passwords. Database passwords are separate from
operating system passwords. Specify a password upon user
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 geqo
+ subsequent connections it will appear as though SET enable_indexscan
TO off; had been called right 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
USAGE>, and ALL PRIVILEGES>. For more
information on the different types of privileges support by
- GRANT reference manual. The right to modify or
+ GRANT page in the &cite-reference;. The right to modify or
destroy an object is always the privilege of the owner only. To
assign privileges, the GRANT command is
used. So, if joe is an existing user, and
database, and how to query it. The middle part lists the
available data types and functions for use in SQL data commands.
The rest of the book treats several aspects that are important for
- tuning a database for optimial performance.
+ tuning a database for optimal performance.