equal to one, an additional decoration that indicates the actual
array dimensions will precede the array structure decoration.
The decoration consists of square braces (<literal>[</> and <literal>]</>)
- around each array dimension's lower and upper bound indicies, plus
- a colon (<literal>:</>) delimiter character inbetween. Delimiting the
+ around each array dimension's lower and upper bound indices, plus
+ a colon (<literal>:</>) delimiter character in between. Delimiting the
array dimension decoration from the array structure decoration is a
single assignment operator (<literal>=</>). For example:
<programlisting>
</para>
<para>
- In a similar fashion, an array with non-default indicies may be specified
+ In a similar fashion, an array with non-default indices may be specified
using the same literal syntax. For example:
<programlisting>
SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
get a usable backup. Half-way measures such as disallowing all
connections will <emphasis>not</emphasis> work
(mainly because <command>tar</command> and similar tools do not take an
- atomic snapshot of the state of the filesystem at a point in
+ atomic snapshot of the state of the file system at a point in
time). Information about stopping the server can be found in
<xref linkend="postmaster-shutdown">. Needless to say that you
also need to shut down the server before restoring the data.
If your database is spread across multiple volumes (for example,
data files and WAL log on different disks) there may not be any way
to obtain exactly-simultaneous frozen snapshots of all the volumes.
- Read your filesystem documentation very carefully before trusting
+ Read your file system documentation very carefully before trusting
to the consistent-snapshot technique in such situations.
</para>
database can be restored to consistency by <quote>replaying</> the
log entries made since the last checkpoint. However, the existence
of the log makes it possible to use a third strategy for backing up
- databases: we can combine a filesystem-level backup with backup of
+ databases: we can combine a file-system-level backup with backup of
the WAL files. If recovery is needed, we restore the backup and
then replay from the backed-up WAL files to bring the backup up to
current time. This approach is more complex to administer than
We do not need a perfectly consistent backup as the starting point.
Any internal inconsistency in the backup will be corrected by log
replay (this is not significantly different from what happens during
- crash recovery). So we don't need filesystem snapshot capability,
+ crash recovery). So we don't need file system snapshot capability,
just <application>tar</> or a similar archiving tool.
</para>
</listitem>
</para>
<para>
- As with the plain filesystem-backup technique, this method can only
+ As with the plain file-system-backup technique, this method can only
support restoration of an entire database cluster, not a subset.
Also, it requires a lot of archival storage: the base backup may be bulky,
and a busy system will generate many megabytes of WAL traffic that
<filename>postgresql.conf</>, <filename>pg_hba.conf</> and
<filename>pg_ident.conf</>) after the initial base backup.
You may wish to keep the configuration files in a location that will
- be backed up by your regular filesystem backup procedures.
+ be backed up by your regular file system backup procedures.
</para>
</sect2>
</listitem>
<listitem>
<para>
- Perform the backup, using any convenient filesystem-backup tool
+ Perform the backup, using any convenient file-system-backup tool
such as <application>tar</> or <application>cpio</>. It is neither
necessary nor desirable to stop normal operation of the database
while you do this.
It is important that the command return nonzero exit status on failure.
The command <emphasis>will</> be asked for log files that are not present
in the archive; it must return nonzero when so asked. This is not an
- error condition. Be aware also that the basename of the <literal>%p</>
+ error condition. Be aware also that the base name of the <literal>%p</>
path will be different from <literal>%f</>; do not expect them to be
interchangeable.
</para>
</term>
<listitem>
<para>
- This parameter specifies the timestamp up to which recovery
+ This parameter specifies the time stamp up to which recovery
will proceed.
At most one of <varname>recovery_target_time</> and
<xref linkend="recovery-target-xid"> can be specified.
<itemizedlist>
<listitem>
<para>
- Operations on non-btree indexes (hash, R-tree, and GiST indexes) are
+ Operations on non-B-tree indexes (hash, R-tree, and GiST indexes) are
not presently WAL-logged, so replay will not update these index types.
The recommended workaround is to manually <command>REINDEX</> each
such index after completing a recovery operation.
<para>
You will always need a SQL dump (<application>pg_dump</> dump) for
- migrating to a new release. Filesystem-level backups (including
+ migrating to a new release. File-system-level backups (including
on-line backups) will not work, for the same reason that you can't
just do the update in-place: the file formats won't necessarily be
compatible across major releases.
represents converting from one type to another and applying a length
coercion in a single step. When no such entry is available, coercion
to a type that uses a type modifier involves two steps, one to
- convert between datatypes and a second to apply the modifier.
+ convert between data types and a second to apply the modifier.
</para>
</sect1>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>
- The OID of the data type that corresponds to this table's rowtype,
+ The OID of the data type that corresponds to this table's row type,
if any (zero for indexes, which have no <structname>pg_type</> entry)
</entry>
</row>
<row>
<entry><structfield>indclass</structfield></entry>
<entry><type>oidvector</type></entry>
- <entry><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.oid</entry>
+ <entry><literal><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.oid</literal></entry>
<entry>
For each column in the index key this contains the OID of
the operator class to use. See
<literal>UNIQUE</> or a <literal>PRIMARY KEY</>, this would not stop the
<structname>capitals</> table from having rows with names duplicating
rows in <structname>cities</>. And those duplicate rows would by
- default show up in SELECTs from <structname>cities</>. In fact, by
+ default show up in queries from <structname>cities</>. In fact, by
default <structname>capitals</> would have no unique constraint at all,
and so could contain multiple rows with the same name.
You could add a unique constraint to <structname>capitals</>, but this
popular interfaces are:
<variablelist>
- <varlistentry>
- <term>ODBC</term>
- <listitem>
- <para>
- This is the most common interface for <application>Windows</>
- applications.
- </para>
- </listitem>
- </varlistentry>
-
<varlistentry>
<term>psqlODBC</term>
<listitem>
separate projects. <application>pgFoundry</> at <ulink
url="http://pgfoundry.org">http://pgfoundry.org</ulink> contains
even more projects. Other projects are not even hosted on these
- servers and you will have to do an internet search to find them.
+ servers and you will have to do an Internet search to find them.
</para>
</sect1>
<productname>PostgreSQL</> was designed from the start to be
extensible. For this reason, extensions loaded into the database can
function just like features that are packaged with the database. The
- <filename>/contrib</> directory shipped with the source code
+ <filename>contrib/</> directory shipped with the source code
contains a large number of extensions. The <filename>README</> file
in that directory contains a summary. They include conversion tools,
full-text indexing, <acronym>XML</> tools, and additional data types
and indexing methods. Other extensions are developed independently,
like <application>PostGIS</>. Even <application>PostgreSQL</>
replication solutions are developed externally. For example,
- <application>Slony</> is a popular master/slave replication solution
+ <application>Slony-I</> is a popular master/slave replication solution
that is developed independently from the main projects.
</para>
<para>
There are several administration tools available for
<productname>PostgreSQL</>. The most popular is
- <application>pgadmin</>, and there are several commercially
+ <application>pgAdmin</>, and there are several commercially
available ones.
</para>
<row>
<entry><literal><function>pg_get_serial_sequence</function>(<parameter>table_name</parameter>, <parameter>column_name</parameter>)</literal></entry>
<entry><type>text</type></entry>
- <entry>get name of the sequence that a serial or bigserial column
+ <entry>get name of the sequence that a <type>serial</type> or <type>bigserial</type> column
uses</entry>
</row>
<row>
This function returns 1 if successful, 0 if not successful.
The process ID (<literal>pid</literal>) of an active backend can be found
from the <structfield>procpid</structfield> column in the
- <structname>pg_stat_activity</structname> view, or by listing the postgres
+ <structname>pg_stat_activity</structname> view, or by listing the <command>postgres</command>
processes on the server with <application>ps</>.
</para>
<para>
To build the <application>PL/Python</> server programming
language, you need a <productname>Python</productname>
- installation with the header files and the distutils module.
- The distutils module is included by default with
+ installation with the header files and the <application>distutils</application> module.
+ The <application>distutils</application> module is included by default with
<productname>Python</productname> 1.6 and later; users of
earlier versions of <productname>Python</productname> will need
to install it.
</para>
<para>
-At present, there is no way to determine the actual datatype inferred for
+At present, there is no way to determine the actual data type inferred for
any parameters whose types are not specified in <parameter>paramTypes[]</>.
This is a <application>libpq</> omission that will probably be rectified
in a future release.
basis, consider doing it with <command>TRUNCATE</command> rather
than using <command>DELETE</command> followed by
<command>VACUUM</command>. <command>TRUNCATE</command> removes the
- entire content of the table immediately, without recquiring a
+ entire content of the table immediately, without requiring a
subsequent <command>VACUUM</command> or <command>VACUUM
FULL</command> to reclaim the now-unused disk space.
</para>
just when you need them the most. Also, on <productname>linux</>,
<application>syslog</> will sync each message to disk, yielding poor
performance. (You can use a <literal>-</> at the start of the file name
- in the <application>syslog</> config file to disable this behavior.)
+ in the <application>syslog</> configuration file to disable this behavior.)
</para>
<para>
<note>
<para>
There is usually not much point in making more than one
- tablespace per logical filesystem, since you cannot control the location
- of individual files within a logical filesystem. However,
+ tablespace per logical file system, since you cannot control the location
+ of individual files within a logical file system. However,
<productname>PostgreSQL</> does not enforce any such limitation, and
- indeed it is not directly aware of the filesystem boundaries on your
+ indeed it is not directly aware of the file system boundaries on your
system. It just stores files in the directories you tell it to use.
</para>
</note>
<para>
Here is an example of a PL/Perl function returning a row set of a
composite type. Since a row set is always a reference to an array
- and a composite type is always a reference to a hash, a rowset of a
+ and a composite type is always a reference to a hash, a row set of a
composite type is a reference to an array of hash references.
<programlisting>
CREATE TYPE testsetperl AS (f1 integer, f2 text, f3 text);
<para>
This example trigger ensures that any insert, update or delete of a row
- in the emp table is recorded (i.e. audited) in the emp_audit table.
+ in the <literal>emp</literal> table is recorded (i.e., audited) in the <literal>emp_audit</literal> table.
The current time and user name are stamped into the row, together with
the type of operation performed on it.
</para>
The function call was completed and returned the result given
in the message.
(Note that the Function Call protocol can only handle a single
- scalar result, not a rowtype or set of results.)
+ scalar result, not a row type or set of results.)
</Para>
</ListItem>
</VarListEntry>
The second variant changes the name of the user. Only a database
superuser can rename user accounts. The session user cannot be
renamed. (Connect as a different user if you need to do that.)
- Because <literal>MD5</>-encrypted passwords use the username as
+ Because <literal>MD5</>-encrypted passwords use the user name as
cryptographic salt, renaming a user clears their <literal>MD5</>
password.
</para>
<listitem>
<para>
In <literal>CSV</> <command>COPY FROM</> mode, process each
- specified column as though it were quoted and hance not a
+ specified column as though it were quoted and hence not a
<literal>NULL</> value. For the default <literal>null string</> in
<literal>CSV</> mode (<literal>''</>), this causes a missing
values to be input as a zero-length strings.
(Bizarrely, the SQL spec demands different behaviors for explicit and
implicit casts in some cases. This argument is supplied for functions
that must implement such casts. It is not recommended that you design
- your own datatypes so that this matters.)
+ your own data types so that this matters.)
</para>
<para>
represents converting from one type to another and applying a length
coercion in a single step. When no such entry is available, coercion
to a type that uses a type modifier involves two steps, one to
- convert between datatypes and a second to apply the modifier.
+ convert between data types and a second to apply the modifier.
</para>
</refsect1>
<para>
While not required, it is recommended that you continue to follow this old
convention of naming cast implementation functions after the target data
- type. Many users are used to being able to cast datatypes using a
+ type. Many users are used to being able to cast data types using a
function-style notation, that is
<replaceable>typename</>(<replaceable>x</>). This notation is in fact
nothing more nor less than a call of the cast implementation function; it
</refsect2>
<refsect2>
- <title>TABLESPACE and USING INDEX TABLESPACE</title>
+ <title>Tablespaces</title>
<para>
The <productname>PostgreSQL</productname> concept of tablespaces is not
- standard.
+ part of the standard. Hence, the clauses <literal>TABLESPACE</literal>
+ and <literal>USING INDEX TABLESPACE</literal> are extensions.
</para>
</refsect2>
</refsect1>
linkend="sql-selectinto" endterm="sql-selectinto-title">, but it is
preferred since it is less likely to be confused with other uses of
the <command>SELECT INTO</> syntax. Furthermore, <command>CREATE
- TABLE AS</command> offers a superset of the functionality offerred
+ TABLE AS</command> offers a superset of the functionality offered
by <command>SELECT INTO</command>.
</para>
frequently executed, the OID counter would be rapidly
incremented. As of <productname>PostgresSQL</productname> 8.0,
the <command>CREATE TABLE AS</command> command allows the user to
- explicitely specify whether OIDs should be included. If the
- presence of OIDs is not explicitely specified,
+ explicitly specify whether OIDs should be included. If the
+ presence of OIDs is not explicitly specified,
the <xref linkend="guc-default-with-oids"> configuration variable is
used. While this variable currently defaults to true, the default
value may be changed in the future. Therefore, applications that
require OIDs in the table created by <command>CREATE TABLE
- AS</command> should explicitely specify <literal>WITH
+ AS</command> should explicitly specify <literal>WITH
OIDS</literal> to ensure compatibility with future versions
of <productname>PostgreSQL</productname>.
</para>
these options are required, defaults do apply. If you omit the host
name, <application>psql</> will connect via a Unix domain socket
to a server on the local host, or via TCP/IP to <literal>localhost</> on machines
- that don't have unix domain sockets. The default port number is compile-time determined.
+ that don't have Unix domain sockets. The default port number is compile-time determined.
Since the database server uses the same default, you will not have
to specify the port in most cases. The default user name is your
Unix user name, as is the default database name. Note that you can't
class="parameter">filename</replaceable> is omitted, the history
is written to the standard output. This option is only available
if <application>psql</application> is configured to use the
- <acronym>GNU</acronym> readline (or history) library.
+ <acronym>GNU</acronym> <application>Readline</application> library.
</para>
<note>
Prompts may contain terminal control characters which, for
example, change the color, background, or style of the prompt
text, or change the title of the terminal window. In order for
- the line editing features of readline to work properly, these
+ the line editing features of <application>Readline</application> to work properly, these
non-printing control characters must be designated as invisible
by surrounding them with <literal>%[</literal> and
<literal>%]</literal>. Multiple pairs of these may occur within
<listitem>
<para>
- Improve btree index performance for duplicate keys (Dmitry Tkach, Tom)
+ Improve B-tree index performance for duplicate keys (Dmitry Tkach, Tom)
</para>
<para>
This improves the way indexes are scanned when many duplicate
and <command>CHECKPOINT</command> (Tom)
</para>
<para>
- In 7.3 and 7.4, a long-running btree index build could block concurrent
+ In 7.3 and 7.4, a long-running B-tree index build could block concurrent
<command>CHECKPOINT</>s from completing, thereby causing WAL bloat because the
WAL log could not be recycled.
</para>
<listitem>
<para>
- Make <function>netmask()</> and <function>hostmask()</> functions
- return maximum-length masklen (Tom)
+ Make <function>netmask</> and <function>hostmask</> functions
+ return maximum-length mask length (Tom)
</para>
</listitem>
<listitem>
<para>
- Add global <application>psql</> config file, <filename>psqlrc.sample</filename>
+ Add global <application>psql</> configuration file, <filename>psqlrc.sample</filename>
(Bruce)
</para>
<para>
<listitem>
<para>
- Many ecpg improvements, including <command>SET DESCRIPTOR</> (Michael)
+ Many ECPG improvements, including <command>SET DESCRIPTOR</> (Michael)
</para>
</listitem>
<listitem>
<para>
- Decouple platform tests from cpu spinlock code (Bruce, Tom)
+ Decouple platform tests from CPU spinlock code (Bruce, Tom)
</para>
</listitem>
<listitem>
<para>
- Make libpq and ecpg build as proper shared libraries on OS X (Tom)
+ Make libpq and ECPG build as proper shared libraries on OS X (Tom)
</para>
</listitem>
<listitem>
<para>
- Overhaul of /contrib/dblink (Joe)
+ Overhaul of <filename>contrib/dblink</> (Joe)
</para>
</listitem>
<listitem>
<para>
- /contrib/dbmirror improvements (Steven Singer)
+ <filename>contrib/dbmirror</> improvements (Steven Singer)
</para>
</listitem>
<listitem>
<para>
- New /contrib/xml2 (John Gray, Torchbox)
+ New <filename>contrib/xml2</> (John Gray, Torchbox)
</para>
</listitem>
<listitem>
<para>
- Update /contrib/mysql
+ Updated <filename>contrib/mysql</filename>
</para>
</listitem>
<listitem>
<para>
- New version of /contrib/btree_gist (Teodor)
+ New version of <filename>contrib/btree_gist</> (Teodor)
</para>
</listitem>
<listitem>
<para>
- New /contrib/trgm, trigram matching for
+ New <filename>contrib/trgm</>, trigram matching for
<productname>PostgreSQL</productname> (Teodor)
</para>
</listitem>
<listitem>
<para>
- Many /contrib/tsearch2 improvements (Teodor)
+ Many <filename>contrib/tsearch2</> improvements (Teodor)
</para>
</listitem>
<listitem>
<para>
- Add double metaphone to /contrib/fuzzystrmatch (Andrew)
+ Add double metaphone to <filename>contrib/fuzzystrmatch</> (Andrew)
</para>
</listitem>
<listitem>
<para>
- Allow /contrib/pg_autovacuum to run as a Windows service (Dave Page)
+ Allow <filename>contrib/pg_autovacuum</> to run as a Windows service (Dave Page)
</para>
</listitem>
<listitem>
<para>
- Add functions to /contrib/dbsize (Andreas Pflug)
+ Add functions to <filename>contrib/dbsize</> (Andreas Pflug)
</para>
</listitem>
<listitem>
<para>
- Remove contrib/pg_logger
+ Removed <filename>contrib/pg_logger</>
</para>
</listitem>
<listitem>
<para>
- Remove contrib/rserv: obsoleted by various separate projects
+ Removed <filename>contrib/rserv</>: obsoleted by various separate projects
</para>
</listitem>
<para>
This is to guard against any possible security issues.
</para></listitem>
-<listitem><para>Avoid using temp files in /tmp in make_oidjoins_check</para>
+<listitem><para>Avoid using temp files in <filename>/tmp</> in <command>make_oidjoins_check</command></para>
<para>
This has been reported as a security issue, though it's hardly worthy of
concern since there is no reason for non-developers to use this script anyway.
In rare cases, a client might think that its last command had succeeded when
it really had been aborted by forced database shutdown.
</para></listitem>
-<listitem><para>Repair bug in pg_stat_get_backend_idset()</para>
+<listitem><para>Repair bug in <function>pg_stat_get_backend_idset</function></para>
<para>
This could lead to misbehavior in some of the system-statistics views.
</para></listitem>
<title>Changes</title>
<itemizedlist>
-<listitem><para>Repair possible crash during concurrent btree index insertions</para>
+<listitem><para>Repair possible crash during concurrent B-tree index insertions</para>
<para>
-This patch fixes a rare case in which concurrent insertions into a btree index
+This patch fixes a rare case in which concurrent insertions into a B-tree index
could result in a server panic. No permanent damage would result, but it's
still worth a re-release. The bug does not exist in pre-7.4 releases.
</para></listitem>
</para></listitem>
<listitem><para>Check HAVING restriction before evaluating result list of an
aggregate plan</para></listitem>
-<listitem><para>Avoid crash when session's current userID is deleted</para></listitem>
+<listitem><para>Avoid crash when session's current user ID is deleted</para></listitem>
<listitem><para>Fix hashed crosstab for zero-rows case (Joe)</para></listitem>
<listitem><para>Force cache update after renaming a column in a foreign key</para></listitem>
<listitem><para>Pretty-print UNION queries correctly</para></listitem>
<para>
A <firstterm>composite type</> describes the structure of a row or record;
- it is in essence just a list of field names and their datatypes.
+ it is in essence just a list of field names and their data types.
<productname>PostgreSQL</productname> allows values of composite types to be
used in many of the same ways that simple types can be used. For example, a
column of a table can be declared to be of a composite type.
</programlisting>
Had we not supplied values for all the subfields of the column, the
- remaining subfields would have been filled with NULLs.
+ remaining subfields would have been filled with null values.
</para>
</sect2>
around the whole value, plus commas (<literal>,</>) between adjacent
items. Whitespace outside the parentheses is ignored, but within the
parentheses it is considered part of the field value, and may or may not be
- significant depending on the input conversion rules for the field datatype.
+ significant depending on the input conversion rules for the field data type.
For example, in
<programlisting>
'( 42)'
</indexterm>
<listitem>
<para>
- Controls the tradeoff between planning time and query plan
+ Controls the trade off between planning time and query plan
efficiency in GEQO. This variable must be an integer in the
range from 1 to 10. The default value is 5. Larger values
increase the time spent doing query planning, but also
- increase the likelyhood that an efficient query plan will be
+ increase the likelihood that an efficient query plan will be
chosen.
</para>
only recognised by session processes, and do not apply to
background processes such as the postmaster. <application>Syslog</>
produces its own
- timestamp and process ID information, so you probably do not want to
+ time stamp and process ID information, so you probably do not want to
use those escapes if you are using <application>syslog</>.
This option can only be set at server start or in the
<filename>postgresql.conf</filename> configuration file.
<tbody>
<row>
<entry><literal>%u</literal></entry>
- <entry>User Name</entry>
- <entry>Yes</entry>
+ <entry>User name</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%d</literal></entry>
- <entry>Database Name</entry>
- <entry>Yes</entry>
+ <entry>Database name</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%r</literal></entry>
- <entry>Remote Hostname or IP address, and Remote Port</entry>
- <entry>Yes</entry>
+ <entry>Remote host name or IP address, and remote port</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%p</literal></entry>
<entry>Process ID</entry>
- <entry>No</entry>
+ <entry>no</entry>
</row>
<row>
<entry><literal>%t</literal></entry>
- <entry>Timestamp</entry>
- <entry>No</entry>
+ <entry>Time stamp</entry>
+ <entry>no</entry>
</row>
<row>
<entry><literal>%i</literal></entry>
- <entry>Command Tag. This is the command which generated the log
- line.</entry>
- <entry>Yes</entry>
+ <entry>Command tag: This is the command that generated the log line.</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%c</literal></entry>
- <entry>Session ID. A unique identifier for each session.
+ <entry>Session ID: A unique identifier for each session.
It is 2 4-byte hexadecimal numbers (without leading zeros)
separated by a dot. The numbers
- are the Session Start Time and the Process ID, so this can also
+ are the session start time and the process ID, so this can also
be used as a space saving way of printing these items.</entry>
- <entry>Yes</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%l</literal></entry>
- <entry>Number of the log line for each process,
- starting at 1</entry>
- <entry>No</entry>
+ <entry>Number of the log line for each process, starting at 1</entry>
+ <entry>no</entry>
</row>
<row>
<entry><literal>%s</literal></entry>
- <entry>Session Start Timestamp</entry>
- <entry>Yes</entry>
+ <entry>Session start time stamp</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%x</literal></entry>
<entry>Transaction ID</entry>
- <entry>Yes</entry>
+ <entry>yes</entry>
</row>
<row>
<entry><literal>%q</literal></entry>
<entry>Does not produce any output, but tells non-session
processes to stop at this point in the string. Ignored by
session processes.</entry>
- <entry>No</entry>
+ <entry>no</entry>
</row>
<row>
<entry><literal>%%</literal></entry>
<entry>Literal <literal>%</></entry>
- <entry>No</entry>
+ <entry>no</entry>
</row>
</tbody>
</tgroup>
<para> It may, however, be necessary to modify the global
<command>ulimit</command> information in
<filename>/etc/security/limits</filename>, as the default hard
- limits for filesizes (<varname>fsize</varname>) and numbers of
+ limits for file sizes (<varname>fsize</varname>) and numbers of
files (<varname>nofiles</varname>) may be too low.
</para>
</listitem>
<para>
On Linux 2.6 and later, a better solution is to modify the kernel's
behavior so that it will not <quote>overcommit</> memory. This is
- done by selecting strict overcommit mode via sysctl:
+ done by selecting strict overcommit mode via <command>sysctl</command>:
<programlisting>
sysctl -w vm.overcommit_memory=2
</programlisting>
<para>
Some vendors' Linux 2.4 kernels are reported to have early versions
- of the 2.6 overcommit sysctl. However, setting
+ of the 2.6 overcommit <command>sysctl</command> parameter. However, setting
<literal>vm.overcommit_memory</> to 2
on a kernel that does not have the relevant code will make
things worse not better. It is recommended that you inspect
<para>
A typical call to <function>ereport</> might look like this:
<programlisting>
- ereport(ERROR,
- (errcode(ERRCODE_DIVISION_BY_ZERO),
- errmsg("division by zero")));
+ereport(ERROR,
+ (errcode(ERRCODE_DIVISION_BY_ZERO),
+ errmsg("division by zero")));
</programlisting>
This specifies error severity level <literal>ERROR</> (a run-of-the-mill
error). The <function>errcode</> call specifies the SQLSTATE error code
<para>
Here is a more complex example:
<programlisting>
- ereport(ERROR,
- (errcode(ERRCODE_AMBIGUOUS_FUNCTION),
- errmsg("function %s is not unique",
- func_signature_string(funcname, nargs,
- actual_arg_types)),
- errhint("Unable to choose a best candidate function. "
- "You may need to add explicit typecasts.")));
+ereport(ERROR,
+ (errcode(ERRCODE_AMBIGUOUS_FUNCTION),
+ errmsg("function %s is not unique",
+ func_signature_string(funcname, nargs,
+ actual_arg_types)),
+ errhint("Unable to choose a best candidate function. "
+ "You may need to add explicit typecasts.")));
</programlisting>
This illustrates the use of format codes to embed run-time values into
a message text. Also, an optional <quote>hint</> message is provided.
<itemizedlist>
<listitem>
<para>
- <function>errcode</>(sqlerrcode) specifies the SQLSTATE error identifier
+ <function>errcode(sqlerrcode)</function> specifies the SQLSTATE error identifier
code for the condition. If this routine is not called, the error
identifier defaults to
<literal>ERRCODE_INTERNAL_ERROR</> when the error severity level is
error level is <literal>WARNING</>, otherwise (for <literal>NOTICE</>
and below) <literal>ERRCODE_SUCCESSFUL_COMPLETION</>.
While these defaults are often convenient, always think whether they
- are appropriate before omitting the <function>errcode</>() call.
+ are appropriate before omitting the <function>errcode()</> call.
</para>
</listitem>
<listitem>
<para>
- <function>errmsg</>(const char *msg, ...) specifies the primary error
+ <function>errmsg(const char *msg, ...)</function> specifies the primary error
message text, and possibly run-time values to insert into it. Insertions
are specified by <function>sprintf</>-style format codes. In addition to
the standard format codes accepted by <function>sprintf</>, the format
</listitem>
<listitem>
<para>
- <function>errmsg_internal</>(const char *msg, ...) is the same as
+ <function>errmsg_internal(const char *msg, ...)</function> is the same as
<function>errmsg</>, except that the message string will not be
included in the internationalization message dictionary.
This should be used for <quote>can't happen</> cases that are probably
</listitem>
<listitem>
<para>
- <function>errdetail</>(const char *msg, ...) supplies an optional
+ <function>errdetail(const char *msg, ...)</function> supplies an optional
<quote>detail</> message; this is to be used when there is additional
information that seems inappropriate to put in the primary message.
The message string is processed in just the same way as for
</listitem>
<listitem>
<para>
- <function>errhint</>(const char *msg, ...) supplies an optional
+ <function>errhint(const char *msg, ...)</function> supplies an optional
<quote>hint</> message; this is to be used when offering suggestions
about how to fix the problem, as opposed to factual details about
what went wrong.
</listitem>
<listitem>
<para>
- <function>errcontext</>(const char *msg, ...) is not normally called
+ <function>errcontext(const char *msg, ...)</function> is not normally called
directly from an <function>ereport</> message site; rather it is used
in <literal>error_context_stack</> callback functions to provide
information about the context in which an error occurred, such as the
</listitem>
<listitem>
<para>
- <function>errposition</>(int cursorpos) specifies the textual location
+ <function>errposition(int cursorpos)</function> specifies the textual location
of an error within a query string. Currently it is only useful for
errors detected in the lexical and syntactic analysis phases of
query processing.
</listitem>
<listitem>
<para>
- <function>errcode_for_file_access</>() is a convenience function that
+ <function>errcode_for_file_access()</> is a convenience function that
selects an appropriate SQLSTATE error identifier for a failure in a
file-access-related system call. It uses the saved
<literal>errno</> to determine which error code to generate.
</listitem>
<listitem>
<para>
- <function>errcode_for_socket_access</>() is a convenience function that
+ <function>errcode_for_socket_access()</> is a convenience function that
selects an appropriate SQLSTATE error identifier for a failure in a
socket-related system call.
</para>
There is an older function <function>elog</> that is still heavily used.
An <function>elog</> call
<programlisting>
- elog(level, "format string", ...);
+elog(level, "format string", ...);
</programlisting>
is exactly equivalent to
<programlisting>
- ereport(level, (errmsg_internal("format string", ...)));
+ereport(level, (errmsg_internal("format string", ...)));
</programlisting>
Notice that the SQLSTATE errcode is always defaulted, and the message
string is not included in the internationalization message dictionary.
<para>
For example, instead of
<programlisting>
- IpcMemoryCreate: shmget(key=%d, size=%u, 0%o) failed: %m
- (plus a long addendum that is basically a hint)
+IpcMemoryCreate: shmget(key=%d, size=%u, 0%o) failed: %m
+(plus a long addendum that is basically a hint)
</programlisting>
-write
+ write
<programlisting>
- Primary: could not create shared memory segment: %m
- Detail: Failed syscall was shmget(key=%d, size=%u, 0%o).
- Hint: the addendum
+Primary: could not create shared memory segment: %m
+Detail: Failed syscall was shmget(key=%d, size=%u, 0%o).
+Hint: the addendum
</programlisting>
</para>
<para>
There is a nontrivial semantic difference between sentences of the form
<programlisting>
- could not open file "%s": %m
+could not open file "%s": %m
</programlisting>
and
<programlisting>
- cannot open file "%s"
+cannot open file "%s"
</programlisting>
The first one means that the attempt to open the file failed. The
message should give a reason, such as <quote>disk full</quote> or
When a message includes text that is generated elsewhere, embed it in
this style:
<programlisting>
- could not open file %s: %m
+could not open file %s: %m
</programlisting>
</para>
Messages should always state the reason why an error occurred.
For example:
<programlisting>
- BAD: could not open file %s
- BETTER: could not open file %s (I/O failure)
+BAD: could not open file %s
+BETTER: could not open file %s (I/O failure)
</programlisting>
If no reason is known you better fix the code.
</para>
not helpful information. If the error text doesn't make as much sense
without the function name, reword it.
<programlisting>
- BAD: pg_atoi: error in "z": can't parse "z"
- BETTER: invalid input syntax for integer: "z"
+BAD: pg_atoi: error in "z": can't parse "z"
+BETTER: invalid input syntax for integer: "z"
</programlisting>
</para>
Avoid mentioning called function names, either; instead say what the code
was trying to do:
<programlisting>
- BAD: open() failed: %m
- BETTER: could not open file %s: %m
+BAD: open() failed: %m
+BETTER: could not open file %s: %m
</programlisting>
If it really seems necessary, mention the system call in the detail
message. (In some cases, providing the actual values passed to the
it's erroneous? <quote>Unrecognized</quote> is often a better choice.
Also, be sure to include the value being complained of.
<programlisting>
- BAD: unknown node type
- BETTER: unrecognized node type: 42
+BAD: unknown node type
+BETTER: unrecognized node type: 42
</programlisting>
</para>
</formalpara>
<refnamediv>
<refname>SPI_getargtypeid</refname>
- <refpurpose>returns the expected typeid for the specified argument of
+ <refpurpose>returns the expected <parameter>typeid</parameter> for the specified argument of
a plan prepared by <function>SPI_prepare</function></refpurpose>
</refnamediv>
<title>Description</title>
<para>
- <function>SPI_getargtypeid</function> returns the Oid representing the type
+ <function>SPI_getargtypeid</function> returns the OID representing the type
id for the <parameter>argIndex</parameter>'th argument of a plan prepared by
<function>SPI_prepare</function>. First argument is at index zero.
</para>
<para>
<function>SPI_returntuple</function> makes a copy of a row in
- the upper executor context, returning it in the form of a rowtype Datum.
- The returned pointer need only be converted to Datum via PointerGetDatum
+ the upper executor context, returning it in the form of a row type <type>Datum</type>.
+ The returned pointer need only be converted to <type>Datum</type> via <function>PointerGetDatum</function>
before returning.
</para>
<para>
By default, the value created by a <literal>ROW</> expression is of
an anonymous record type. If necessary, it can be cast to a named
- composite type — either the rowtype of a table, or a composite type
+ composite type — either the row type of a table, or a composite type
created with <command>CREATE TYPE AS</>. An explicit cast may be needed
to avoid ambiguity. For example:
<programlisting>
<term><structfield>tg_trigtuplebuf</></term>
<listitem>
<para>
- The buffer containing tg_trigtuple, or InvalidBuffer if there
+ The buffer containing <structfield>tg_trigtuple</structfield>, or <symbol>InvalidBuffer</symbol> if there
is no such tuple or it is not stored in a disk buffer.
</para>
</listitem>
<term><structfield>tg_newtuplebuf</></term>
<listitem>
<para>
- The buffer containing tg_newtuple, or InvalidBuffer if there
+ The buffer containing <structfield>tg_newtuple</structfield>, or <symbol>InvalidBuffer</symbol> if there
is no such tuple or it is not stored in a disk buffer.
</para>
</listitem>
<para>
A trigger function must return either a
<structname>HeapTuple</> pointer or a <symbol>NULL</> pointer
- (<emphasis>not</> a SQL NULL, that is, do not set isNull true).
+ (<emphasis>not</> an SQL null value, that is, do not set <parameter>isNull</parameter> true).
Be careful to return either
<structfield>tg_trigtuple</> or <structfield>tg_newtuple</>,
as appropriate, if you don't want to modify the row being operated on.
There are two ways you can build a composite data value (henceforth
a <quote>tuple</>): you can build it from an array of Datum values,
or from an array of C strings that can be passed to the input
- conversion functions of the tuple's column datatypes. In either
+ conversion functions of the tuple's column data types. In either
case, you first need to obtain or construct a <structname>TupleDesc</>
descriptor for the tuple structure. When working with Datums, you
pass the <structname>TupleDesc</> to <function>BlessTupleDesc</>,
for all calls within a single surrounding query. This category
allows the optimizer to optimize away multiple calls of the function
within a single query. In particular, it is safe to use an expression
- containing such a function in an indexscan condition. (Since an
- indexscan will evaluate the comparison value only once, not once at
+ containing such a function in an index scan condition. (Since an
+ index scan will evaluate the comparison value only once, not once at
each row, it is not valid to use a <literal>VOLATILE</> function in
- an indexscan condition.)
+ an index scan condition.)
</para>
</listitem>
<listitem>
projects / users / bernd / postgres.git / commitdiff