mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-30 19:00:29 +08:00
Spell checker run
This commit is contained in:
parent
cc4f22c167
commit
5ec30faee6
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.40 2004/11/27 21:27:05 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.41 2004/12/13 18:05:07 petere Exp $ -->
|
||||
|
||||
<sect1 id="arrays">
|
||||
<title>Arrays</title>
|
||||
@ -547,8 +547,8 @@ SELECT * FROM sal_emp WHERE 10000 = ALL (pay_by_quarter);
|
||||
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>
|
||||
@ -569,7 +569,7 @@ SELECT ARRAY[1,2] || ARRAY[[3,4]] AS array;
|
||||
</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
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.52 2004/11/17 18:29:02 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.53 2004/12/13 18:05:07 petere Exp $
|
||||
-->
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
@ -317,7 +317,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
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.
|
||||
@ -365,7 +365,7 @@ tar -cf backup.tar /usr/local/pgsql/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>
|
||||
|
||||
@ -402,7 +402,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
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
|
||||
@ -414,7 +414,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
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>
|
||||
@ -449,7 +449,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
</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
|
||||
@ -618,7 +618,7 @@ archive_command = 'test ! -f .../%f && cp %p .../%f'
|
||||
<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>
|
||||
|
||||
@ -655,7 +655,7 @@ SELECT pg_start_backup('label');
|
||||
</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.
|
||||
@ -867,7 +867,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
|
||||
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>
|
||||
@ -948,7 +948,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
|
||||
</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.
|
||||
@ -1098,7 +1098,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
|
||||
<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.
|
||||
@ -1196,7 +1196,7 @@ psql template1 < backup
|
||||
|
||||
<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.
|
||||
|
@ -1,6 +1,6 @@
|
||||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
$PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.93 2004/12/01 19:00:27 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.94 2004/12/13 18:05:07 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="catalogs">
|
||||
@ -980,7 +980,7 @@
|
||||
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>
|
||||
|
||||
@ -1037,7 +1037,7 @@
|
||||
<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>
|
||||
@ -2010,7 +2010,7 @@
|
||||
<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
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.33 2004/11/27 21:27:06 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.34 2004/12/13 18:05:08 petere Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -1148,7 +1148,7 @@ WHERE c.altitude > 500 and c.tableoid = p.oid;
|
||||
<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
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.5 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="external-projects">
|
||||
@ -43,16 +43,6 @@ $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40
|
||||
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>
|
||||
@ -155,7 +145,7 @@ $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40
|
||||
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>
|
||||
@ -171,21 +161,21 @@ $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40
|
||||
<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>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.229 2004/12/03 18:34:31 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.230 2004/12/13 18:05:08 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -8553,7 +8553,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
|
||||
<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>
|
||||
@ -8801,7 +8801,7 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
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>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.211 2004/12/11 20:54:14 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.212 2004/12/13 18:05:08 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
@ -173,8 +173,8 @@ su - postgres
|
||||
<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.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.170 2004/12/02 15:32:52 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.171 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq">
|
||||
@ -1203,7 +1203,7 @@ about such errors.
|
||||
</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.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.38 2004/11/15 06:32:14 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="maintenance">
|
||||
@ -183,7 +183,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.38 2004/11/15 06:32:14 neil
|
||||
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>
|
||||
@ -502,7 +502,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
|
||||
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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.37 2004/12/02 19:28:48 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.38 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="managing-databases">
|
||||
@ -379,10 +379,10 @@ CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
|
||||
<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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.33 2004/12/11 20:03:37 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.34 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plperl">
|
||||
@ -295,7 +295,7 @@ $$ LANGUAGE plperl;
|
||||
<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);
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.50 2004/12/03 17:12:09 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.51 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
@ -2576,7 +2576,7 @@ CREATE TRIGGER emp_stamp BEFORE INSERT OR UPDATE ON emp
|
||||
|
||||
<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>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.55 2004/11/15 06:32:14 neilc Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.56 2004/12/13 18:05:08 petere Exp $ -->
|
||||
|
||||
<chapter id="protocol">
|
||||
<title>Frontend/Backend Protocol</title>
|
||||
@ -902,7 +902,7 @@
|
||||
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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_user.sgml,v 1.33 2004/05/06 16:59:16 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_user.sgml,v 1.34 2004/12/13 18:05:10 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -57,7 +57,7 @@ ALTER USER <replaceable class="PARAMETER">name</replaceable> RESET <replaceable>
|
||||
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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/copy.sgml,v 1.61 2004/12/02 15:32:53 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/copy.sgml,v 1.62 2004/12/13 18:05:10 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -231,7 +231,7 @@ COPY <replaceable class="parameter">tablename</replaceable> [ ( <replaceable cla
|
||||
<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.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/create_cast.sgml,v 1.19 2004/11/27 21:27:07 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/create_cast.sgml,v 1.20 2004/12/13 18:05:10 petere Exp $ -->
|
||||
|
||||
<refentry id="SQL-CREATECAST">
|
||||
<refmeta>
|
||||
@ -198,7 +198,7 @@ SELECT 'The time is ' || CAST(now() AS text);
|
||||
(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>
|
||||
@ -219,7 +219,7 @@ SELECT 'The time is ' || CAST(now() AS text);
|
||||
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>
|
||||
@ -251,7 +251,7 @@ SELECT 'The time is ' || CAST(now() AS text);
|
||||
<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
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.87 2004/11/27 21:27:07 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.88 2004/12/13 18:05:10 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -974,11 +974,12 @@ CREATE TABLE cinemas (
|
||||
</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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.25 2004/11/27 21:27:07 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.26 2004/12/13 18:05:10 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -136,7 +136,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name
|
||||
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>
|
||||
|
||||
@ -150,13 +150,13 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name
|
||||
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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.123 2004/10/06 18:39:15 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.124 2004/12/13 18:05:10 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -493,7 +493,7 @@ PostgreSQL documentation
|
||||
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
|
||||
@ -1603,7 +1603,7 @@ lo_import 152801
|
||||
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>
|
||||
@ -2368,7 +2368,7 @@ testdb=> <userinput>\set content '\'' `sed -e "s/'/\\\\\\'/g" < my_file.txt` '\'
|
||||
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
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.316 2004/12/13 18:05:08 petere Exp $
|
||||
-->
|
||||
|
||||
<appendix id="release">
|
||||
@ -519,7 +519,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<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
|
||||
@ -1244,7 +1244,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
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>
|
||||
@ -1426,8 +1426,8 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<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>
|
||||
|
||||
@ -1810,7 +1810,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<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>
|
||||
@ -1983,7 +1983,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Many ecpg improvements, including <command>SET DESCRIPTOR</> (Michael)
|
||||
Many ECPG improvements, including <command>SET DESCRIPTOR</> (Michael)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2076,7 +2076,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Decouple platform tests from cpu spinlock code (Bruce, Tom)
|
||||
Decouple platform tests from CPU spinlock code (Bruce, Tom)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2224,7 +2224,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<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>
|
||||
|
||||
@ -2238,74 +2238,74 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.315 2004/12/01 19:00:27 tgl Exp
|
||||
|
||||
<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>
|
||||
|
||||
@ -2355,7 +2355,7 @@ left-side rows given just the right data distribution.
|
||||
<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.
|
||||
@ -2366,7 +2366,7 @@ result</para>
|
||||
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>
|
||||
@ -2410,9 +2410,9 @@ ECPG prepare statement</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>
|
||||
@ -2456,7 +2456,7 @@ since <productname>PostgreSQL</productname> 7.1.
|
||||
</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>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/rowtypes.sgml,v 2.2 2004/06/09 19:08:14 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/rowtypes.sgml,v 2.3 2004/12/13 18:05:09 petere Exp $ -->
|
||||
|
||||
<sect1 id="rowtypes">
|
||||
<title>Composite Types</title>
|
||||
@ -13,7 +13,7 @@
|
||||
|
||||
<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.
|
||||
@ -238,7 +238,7 @@ INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);
|
||||
</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>
|
||||
|
||||
@ -253,7 +253,7 @@ INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);
|
||||
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)'
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.295 2004/12/05 20:05:47 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.296 2004/12/13 18:05:09 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
@ -1946,11 +1946,11 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
|
||||
</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>
|
||||
|
||||
@ -2643,7 +2643,7 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
|
||||
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.
|
||||
@ -2660,71 +2660,69 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
|
||||
<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>
|
||||
@ -4477,7 +4475,7 @@ sysctl -w kern.sysv.shmall
|
||||
<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>
|
||||
@ -4668,7 +4666,7 @@ Out of Memory: Killed process 12345 (postmaster).
|
||||
<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>
|
||||
@ -4680,7 +4678,7 @@ sysctl -w vm.overcommit_memory=2
|
||||
|
||||
<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
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.15 2004/11/15 06:32:14 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.16 2004/12/13 18:05:09 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="source">
|
||||
@ -109,9 +109,9 @@ less -x4
|
||||
<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
|
||||
@ -124,13 +124,13 @@ less -x4
|
||||
<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.
|
||||
@ -141,7 +141,7 @@ less -x4
|
||||
<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
|
||||
@ -149,12 +149,12 @@ less -x4
|
||||
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
|
||||
@ -177,7 +177,7 @@ less -x4
|
||||
</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
|
||||
@ -186,7 +186,7 @@ less -x4
|
||||
</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
|
||||
@ -195,7 +195,7 @@ less -x4
|
||||
</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.
|
||||
@ -205,7 +205,7 @@ less -x4
|
||||
</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
|
||||
@ -218,7 +218,7 @@ less -x4
|
||||
</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.
|
||||
@ -226,7 +226,7 @@ less -x4
|
||||
</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.
|
||||
@ -236,7 +236,7 @@ less -x4
|
||||
</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>
|
||||
@ -248,11 +248,11 @@ less -x4
|
||||
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.
|
||||
@ -297,14 +297,14 @@ less -x4
|
||||
<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>
|
||||
|
||||
@ -461,11 +461,11 @@ write
|
||||
<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
|
||||
@ -525,7 +525,7 @@ and
|
||||
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>
|
||||
|
||||
@ -546,8 +546,8 @@ and
|
||||
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>
|
||||
@ -563,8 +563,8 @@ and
|
||||
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>
|
||||
|
||||
@ -572,8 +572,8 @@ and
|
||||
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
|
||||
@ -622,8 +622,8 @@ and
|
||||
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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.35 2004/09/13 20:05:25 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.36 2004/12/13 18:05:09 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="spi">
|
||||
@ -825,7 +825,7 @@ int SPI_getargcount(void * <parameter>plan</parameter>)
|
||||
|
||||
<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>
|
||||
|
||||
@ -841,7 +841,7 @@ Oid SPI_getargtypeid(void * <parameter>plan</parameter>, int <parameter>argIndex
|
||||
<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>
|
||||
@ -2482,8 +2482,8 @@ HeapTupleHeader SPI_returntuple(HeapTuple <parameter>row</parameter>, TupleDesc
|
||||
|
||||
<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>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.97 2004/11/15 06:32:14 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.98 2004/12/13 18:05:09 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -1547,7 +1547,7 @@ SELECT ROW(1,2.5,'this is a test');
|
||||
<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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.37 2004/10/30 20:52:46 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.38 2004/12/13 18:05:09 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="triggers">
|
||||
@ -434,7 +434,7 @@ typedef struct Trigger
|
||||
<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>
|
||||
@ -444,7 +444,7 @@ typedef struct Trigger
|
||||
<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>
|
||||
@ -456,7 +456,7 @@ typedef struct Trigger
|
||||
<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.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.89 2004/11/15 06:32:14 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.90 2004/12/13 18:05:09 petere Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xfunc">
|
||||
@ -1930,7 +1930,7 @@ CREATE FUNCTION c_overpaid(emp, integer) RETURNS boolean
|
||||
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</>,
|
||||
@ -2494,10 +2494,10 @@ CREATE FUNCTION test(int, int) RETURNS int
|
||||
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>
|
||||
|
Loading…
Reference in New Issue
Block a user