mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-24 18:55:04 +08:00
Spell checking and markup refinement
This commit is contained in:
parent
0ee391b77a
commit
c13dc6402b
@ -818,8 +818,8 @@ SELECT pg_stop_backup();
|
||||
the equivalent of <function>pg_start_backup()</>, copy and
|
||||
<function>pg_stop_backup()</> steps automatically, and transfers the
|
||||
backup over a regular <productname>PostgreSQL</productname> connection
|
||||
using the replication protocol, instead of requiring filesystem level
|
||||
access. pg_basebackup does not interfere with filesystem level backups
|
||||
using the replication protocol, instead of requiring file system level
|
||||
access. <command>pg_basebackup</command> does not interfere with file system level backups
|
||||
taken using <function>pg_start_backup()</>/<function>pg_stop_backup()</>.
|
||||
</para>
|
||||
|
||||
|
@ -25,7 +25,7 @@
|
||||
standard B-tree code: the ability to enforce uniqueness. However,
|
||||
they provide some other features that are not available with a B-tree
|
||||
index, as described below. Also, these operator classes are useful
|
||||
when a multi-column GiST index is needed, wherein some of the columns
|
||||
when a multicolumn GiST index is needed, wherein some of the columns
|
||||
are of data types that are only indexable with GiST but other columns
|
||||
are just simple data types. Lastly, these operator classes are useful for
|
||||
GiST testing and as a base for developing other GiST operator classes.
|
||||
@ -55,7 +55,7 @@
|
||||
<title>Example Usage</title>
|
||||
|
||||
<para>
|
||||
Simple example using btree_gist instead of btree:
|
||||
Simple example using <literal>btree_gist</literal> instead of <literal>btree</literal>:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -1129,7 +1129,7 @@
|
||||
<entry><literal><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.oid</literal></entry>
|
||||
<entry>
|
||||
The defined collation of the column, or zero if the column is
|
||||
not of a collatable datatype.
|
||||
not of a collatable data type.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1294,7 +1294,7 @@
|
||||
Password (possibly encrypted); null if none. If the password
|
||||
is encrypted, this column will begin with the string <literal>md5</>
|
||||
followed by a 32-character hexadecimal MD5 hash. The MD5 hash
|
||||
will be of the user's password concatenated to their username.
|
||||
will be of the user's password concatenated to their user name.
|
||||
For example, if user <literal>joe</> has password <literal>xyzzy</>,
|
||||
<productname>PostgreSQL</> will store the md5 hash of
|
||||
<literal>xyzzyjoe</>. A password that does not follow that
|
||||
|
@ -3892,7 +3892,7 @@ FROM pg_stat_activity;
|
||||
This option emits log lines in comma-separated-values
|
||||
(<acronym>CSV</>) format,
|
||||
with these columns:
|
||||
timestamp with milliseconds,
|
||||
time stamp with milliseconds,
|
||||
user name,
|
||||
database name,
|
||||
process ID,
|
||||
@ -4936,7 +4936,7 @@ SET XML OPTION { DOCUMENT | CONTENT };
|
||||
Sets the collection of time zone abbreviations that will be accepted
|
||||
by the server for datetime input. The default is <literal>'Default'</>,
|
||||
which is a collection that works in most of the world; there are
|
||||
also 'Australia' and 'India', and other collections can be defined
|
||||
also <literal>'Australia'</literal> and <literal>'India'</literal>, and other collections can be defined
|
||||
for a particular installation. See <xref
|
||||
linkend="datetime-appendix"> for more information.
|
||||
</para>
|
||||
@ -6284,7 +6284,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
|
||||
be present in the table. It is useful for recovering data if
|
||||
corruption has occurred due to a hardware or software error. You should
|
||||
generally not set this on until you have given up hope of recovering
|
||||
data from the damaged pages of a table. Zerod-out pages are not
|
||||
data from the damaged pages of a table. Zeroed-out pages are not
|
||||
forced to disk so it is recommended to recreate the table or
|
||||
the index before turning this parameter off again. The
|
||||
default setting is <literal>off</>, and it can only be changed
|
||||
|
@ -407,7 +407,7 @@ EXEC SQL SELECT foo INTO :FooBar FROM table1 WHERE ascii = 'doodad';
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Also, a configuration parameter can be retreived with the
|
||||
Also, a configuration parameter can be retrieved with the
|
||||
<literal>SHOW</literal> command:
|
||||
<programlisting>
|
||||
EXEC SQL SHOW search_path INTO :var;
|
||||
@ -983,7 +983,7 @@ VARCHAR v2[128];
|
||||
the pgtypes library. The pgtypes library, described in detail
|
||||
in <xref linkend="ecpg-pgtypes"> contains basic functions to deal
|
||||
with those types, such that you do not need to send a query to
|
||||
the SQL server just for adding an interval to a timestamp for
|
||||
the SQL server just for adding an interval to a time stamp for
|
||||
example.
|
||||
</para>
|
||||
|
||||
@ -1038,9 +1038,9 @@ ts = 2010-06-27 18:03:56.949343
|
||||
|
||||
<para>
|
||||
In addition, the DATE type can be handled in the same way. The
|
||||
program has to include pg_types_date.h, declare a host variable
|
||||
program has to include <filename>pg_types_date.h</filename>, declare a host variable
|
||||
as the date type and convert a DATE value into a text form using
|
||||
PGTYPESdate_to_asc() function. For more details about the
|
||||
<function>PGTYPESdate_to_asc()</function> function. For more details about the
|
||||
pgtypes library functions, see <xref linkend="ecpg-pgtypes">.
|
||||
</para>
|
||||
</sect4>
|
||||
@ -1173,12 +1173,12 @@ EXEC SQL END DECLARE SECTION;
|
||||
is a way to store some text string in <type>char[]</type>
|
||||
or <type>VARCHAR[]</type>, as
|
||||
explained <xref linkend="ecpg-char">. The second use case is to
|
||||
retreive multiple rows from a query result without using a
|
||||
retrieve multiple rows from a query result without using a
|
||||
cursor. Without an array, to process a query result consisting
|
||||
of multiple rows, it is required to use a cursor and
|
||||
the <command>FETCH</command> command. But with array host
|
||||
variables, multiple rows can be received at once. The length of
|
||||
the array has to be defined to be able to accomodate all rows,
|
||||
the array has to be defined to be able to accommodate all rows,
|
||||
otherwise a buffer overflow will likely occur.
|
||||
</para>
|
||||
|
||||
@ -1239,7 +1239,7 @@ oid=0, dbname=
|
||||
|
||||
<para>
|
||||
The following example retrieves OIDs, names, and sizes of the
|
||||
avilable databases from the <literal>pg_database</literal>
|
||||
available databases from the <literal>pg_database</literal>
|
||||
system table and using
|
||||
the <function>pg_database_size()</function> function. In this
|
||||
example, a structure variable <varname>dbinfo_t</varname> with
|
||||
@ -3006,7 +3006,7 @@ int PGTYPEStimestamp_fmt_asc(timestamp *ts, char *output, int str_len, char *fmt
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>%p</literal> - is replaced by national representation of
|
||||
either "ante meridiem" or "post meridiem" as appropriate.
|
||||
either <quote>ante meridiem</quote> or <quote>post meridiem</quote> as appropriate.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -3852,7 +3852,7 @@ EXEC SQL DESCRIBE prepared_statement INTO mysqlda;
|
||||
</procedure>
|
||||
|
||||
<sect3>
|
||||
<title>SQLDA Datac Structure</title>
|
||||
<title>SQLDA Data Structure</title>
|
||||
|
||||
<para>
|
||||
SQLDA uses three data structure
|
||||
@ -4080,7 +4080,7 @@ struct sqlname
|
||||
</sect3>
|
||||
|
||||
<sect3 id="ecpg-sqlda-output">
|
||||
<title>Retreiving a Result Set Using an SQLDA</title>
|
||||
<title>Retrieving a Result Set Using an SQLDA</title>
|
||||
|
||||
<procedure>
|
||||
<para>
|
||||
@ -4265,9 +4265,9 @@ free(sqlda2);
|
||||
|
||||
<para>
|
||||
This application joins two system tables, pg_database and
|
||||
pg_stat_database on the database oid, and also fetches and shows
|
||||
the database statistics which are retreived by two input
|
||||
parameters (a database "postgres", and oid "1").
|
||||
pg_stat_database on the database OID, and also fetches and shows
|
||||
the database statistics which are retrieved by two input
|
||||
parameters (a database <literal>postgres</literal>, and OID <literal>1</literal>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -5832,7 +5832,7 @@ ECPG = ecpg
|
||||
<para>
|
||||
Large object functions have to be called in a transaction block, so
|
||||
when autocommit is off, <command>BEGIN</command> commands have to
|
||||
be isssued explicitly.
|
||||
be issued explicitly.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -6616,7 +6616,7 @@ DECLARE <replaceable class="PARAMETER">cursor_name</replaceable> [ BINARY ] [ IN
|
||||
<term><replaceable class="PARAMETER">prepared_name</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of a prepared query, either as an SQL identfier or a
|
||||
The name of a prepared query, either as an SQL identifier or a
|
||||
host variable.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -7477,7 +7477,7 @@ SET DESCRIPTOR <replaceable class="PARAMETER">descriptor_name</replaceable> VALU
|
||||
<term><replaceable class="PARAMETER">descriptor_item</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
A token identifiying which item of information to set in the
|
||||
A token identifying which item of information to set in the
|
||||
descriptor. See <xref linkend="ecpg-named-descriptors"> for a
|
||||
list of supported items.
|
||||
</para>
|
||||
@ -8461,7 +8461,7 @@ int dectoasc(decimal *np, char *cp, int len, int right)
|
||||
<literal>right</> to -1 indicates that all available decimal digits
|
||||
should be included in the output. If the length of the output buffer,
|
||||
which is indicated by <literal>len</> is not sufficient to hold the
|
||||
textual representation including the trailing NUL character, only a
|
||||
textual representation including the trailing zero byte, only a
|
||||
single <literal>*</> character is stored in the result and -1 is
|
||||
returned.
|
||||
</para>
|
||||
@ -8556,7 +8556,7 @@ int rdatestr(date d, char *str);
|
||||
The function receives two arguments, the first one is the date to
|
||||
convert (<literal>d</> and the second one is a pointer to the target
|
||||
string. The output format is always <literal>yyyy-mm-dd</>, so you need
|
||||
to allocate at least 11 bytes (including the NUL-terminator) for the
|
||||
to allocate at least 11 bytes (including the zero-byte terminator) for the
|
||||
string.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -288,7 +288,7 @@
|
||||
|
||||
<para>
|
||||
A useful extension to <productname>PostgreSQL</> typically includes
|
||||
multiple SQL objects; for example, a new datatype will require new
|
||||
multiple SQL objects; for example, a new data type will require new
|
||||
functions, new operators, and probably new index operator classes.
|
||||
It is helpful to collect all these objects into a single package
|
||||
to simplify database management. <productname>PostgreSQL</> calls
|
||||
|
@ -10,7 +10,7 @@
|
||||
<para>
|
||||
The <filename>file_fdw</> module provides the foreign-data wrapper
|
||||
<function>file_fdw</function>, which can be used to access data
|
||||
files in the server's filesystem. Data files must be in a format
|
||||
files in the server's file system. Data files must be in a format
|
||||
that can be read by <command>COPY FROM</command>;
|
||||
see <xref linkend="sql-copy"> for details.
|
||||
</para>
|
||||
|
@ -9103,7 +9103,7 @@ SELECT xmlagg(x) FROM (SELECT * FROM test ORDER BY y DESC) AS tab;
|
||||
</para>
|
||||
|
||||
<sect3>
|
||||
<title>IS DOCUMENT</title>
|
||||
<title><literal>IS DOCUMENT</literal></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>IS DOCUMENT</primary>
|
||||
@ -9123,7 +9123,7 @@ SELECT xmlagg(x) FROM (SELECT * FROM test ORDER BY y DESC) AS tab;
|
||||
</sect3>
|
||||
|
||||
<sect3 id="xml-exists">
|
||||
<title>XMLEXISTS</title>
|
||||
<title><literal>XMLEXISTS</literal></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>XMLEXISTS</primary>
|
||||
@ -9165,7 +9165,7 @@ SELECT xmlexists('//town[text() = ''Toronto'']' PASSING BY REF '<towns><town>Tor
|
||||
</sect3>
|
||||
|
||||
<sect3 id="xml-is-well-formed">
|
||||
<title>xml_is_well_formed</title>
|
||||
<title><literal>xml_is_well_formed</literal></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>xml_is_well_formed</primary>
|
||||
@ -9187,7 +9187,7 @@ SELECT xmlexists('//town[text() = ''Toronto'']' PASSING BY REF '<towns><town>Tor
|
||||
|
||||
<para>
|
||||
These functions check whether a <type>text</> string is well-formed XML,
|
||||
returning a boolean result.
|
||||
returning a Boolean result.
|
||||
<function>xml_is_well_formed_document</function> checks for a well-formed
|
||||
document, while <function>xml_is_well_formed_content</function> checks
|
||||
for well-formed content. <function>xml_is_well_formed</function> does
|
||||
@ -9324,7 +9324,7 @@ SELECT xpath('//mydefns:b/text()', '<a xmlns="http://example.com"><b>test</b></a
|
||||
The function <function>xpath_exists</function> is a specialized form
|
||||
of the <function>xpath</function> function. Instead of returning the
|
||||
individual XML values that satisfy the XPath, this function returns a
|
||||
boolean indicating whether the query was satisfied or not. This
|
||||
Boolean indicating whether the query was satisfied or not. This
|
||||
function is equivalent to the standard <literal>XMLEXISTS</> predicate,
|
||||
except that it also offers support for a namespace mapping argument.
|
||||
</para>
|
||||
@ -13685,12 +13685,12 @@ SELECT typlen FROM pg_type WHERE oid = pg_typeof(33);
|
||||
<row>
|
||||
<entry><literal><function>txid_snapshot_xmax(<parameter>txid_snapshot</parameter>)</function></literal></entry>
|
||||
<entry><type>bigint</type></entry>
|
||||
<entry>get xmax of snapshot</entry>
|
||||
<entry>get <literal>xmax</literal> of snapshot</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>txid_snapshot_xmin(<parameter>txid_snapshot</parameter>)</function></literal></entry>
|
||||
<entry><type>bigint</type></entry>
|
||||
<entry>get xmin of snapshot</entry>
|
||||
<entry>get <literal>xmin</literal> of snapshot</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>txid_visible_in_snapshot(<parameter>bigint</parameter>, <parameter>txid_snapshot</parameter>)</function></literal></entry>
|
||||
@ -14218,7 +14218,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
|
||||
<literal><function>pg_last_xact_replay_timestamp()</function></literal>
|
||||
</entry>
|
||||
<entry><type>timestamp with time zone</type></entry>
|
||||
<entry>Get timestamp of last transaction replayed during recovery.
|
||||
<entry>Get time stamp of last transaction replayed during recovery.
|
||||
This is the time at which the commit or abort WAL record for that
|
||||
transaction was generated on the primary.
|
||||
If no transactions have been replayed during recovery, this function
|
||||
@ -14638,7 +14638,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
|
||||
</indexterm>
|
||||
<para>
|
||||
<function>pg_read_binary_file</> is similar to
|
||||
<function>pg_read_file</>, except that the result is a bytea value;
|
||||
<function>pg_read_file</>, except that the result is a <type>bytea</type> value;
|
||||
accordingly, no encoding checks are performed.
|
||||
In combination with the <function>convert_from</> function, this function
|
||||
can be used to read a file in a specified encoding:
|
||||
|
@ -1144,7 +1144,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
|
||||
<para>
|
||||
To trigger failover of a log-shipping standby server,
|
||||
run <command>pg_ctl promote</> or create a trigger
|
||||
file with the filename and path specified by the <varname>trigger_file</>
|
||||
file with the file name and path specified by the <varname>trigger_file</>
|
||||
setting in <filename>recovery.conf</>. If you're planning to use
|
||||
<command>pg_ctl promote</> to fail over, <varname>trigger_file</> is
|
||||
not required. If you're setting up the reporting servers that are
|
||||
|
@ -1989,7 +1989,7 @@ kill `cat /usr/local/pgsql/data/postmaster.pid`
|
||||
<para>
|
||||
PostgreSQL works on AIX, but getting it installed properly can be
|
||||
challenging. AIX versions from 4.3.3 to 6.1 are considered supported.
|
||||
You can use GCC or the native IBM compiler xlc. In
|
||||
You can use GCC or the native IBM compiler <command>xlc</command>. In
|
||||
general, using recent versions of AIX and PostgreSQL helps. Check
|
||||
the build farm for up to date information about which versions of
|
||||
AIX are known to work.
|
||||
@ -2817,7 +2817,7 @@ MANPATH=/usr/lib/scohelp/%L/man:/usr/dt/man:/usr/man:/usr/share/man:scohelp:/usr
|
||||
You can build with either GCC or Sun's compiler suite. For
|
||||
better code optimization, Sun's compiler is strongly recommended
|
||||
on the SPARC architecture. We have heard reports of problems
|
||||
when using GCC 2.95.1; gcc 2.95.3 or later is recommended. If
|
||||
when using GCC 2.95.1; GCC 2.95.3 or later is recommended. If
|
||||
you are using Sun's compiler, be careful not to select
|
||||
<filename>/usr/ucb/cc</filename>;
|
||||
use <filename>/opt/SUNWspro/bin/cc</filename>.
|
||||
|
@ -556,7 +556,7 @@ PGconn *PQconnectdbParams(const char **keywords, const char **values, int expand
|
||||
parameter can be used to achieve the kind of server
|
||||
authentication that SSL certificates achieve on TCP/IP
|
||||
connections. (Note that if the Unix-domain socket is
|
||||
in <filename>/tmp</filename> or another publically writable
|
||||
in <filename>/tmp</filename> or another publicly writable
|
||||
location, any user could start a server there. Use this
|
||||
parameter to ensure that you are connected to a server run
|
||||
by a trusted user,
|
||||
@ -5410,7 +5410,7 @@ int PQlibVersion(void);
|
||||
|
||||
<para>
|
||||
The result of this function can be used to determine, at
|
||||
runtime, if specific functionality is available in the currently
|
||||
run time, if specific functionality is available in the currently
|
||||
loaded version of libpq. The function can be used, for example,
|
||||
to determine which connection options are available for
|
||||
<function>PQconnectdb</> or if the <literal>hex</> <type>bytea</>
|
||||
|
@ -245,15 +245,15 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<entry><structname>pg_stat_activity</><indexterm><primary>pg_stat_activity</primary></indexterm></entry>
|
||||
<entry>One row per server process, showing database OID, database
|
||||
name, process <acronym>ID</>, user OID, user name, application name,
|
||||
client's address, hostname (if available), and port number, times at
|
||||
client's address, host name (if available), and port number, times at
|
||||
which the server process, current transaction, and current query began
|
||||
execution, process's waiting status, and text of the current query.
|
||||
The columns that report data on the current query are available unless
|
||||
the parameter <varname>track_activities</varname> has been turned off.
|
||||
Furthermore, these columns are only visible if the user examining
|
||||
the view is a superuser or the same as the user owning the process
|
||||
being reported on. The client's hostname will be available only if
|
||||
<xref linkend="guc-log-hostname"> is set or if the user's hostname
|
||||
being reported on. The client's host name will be available only if
|
||||
<xref linkend="guc-log-hostname"> is set or if the user's host name
|
||||
needed to be looked up during <filename>pg_hba.conf</filename>
|
||||
processing.
|
||||
</entry>
|
||||
@ -300,7 +300,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<row>
|
||||
<entry><structname>pg_stat_replication</><indexterm><primary>pg_stat_replication</primary></indexterm></entry>
|
||||
<entry>One row per WAL sender process, showing process <acronym>ID</>,
|
||||
user OID, user name, application name, client's address, hostname
|
||||
user OID, user name, application name, client's address, host name
|
||||
(if available) and port number, time at which the server process began
|
||||
execution, and the current WAL sender state and transaction log
|
||||
location. In addition, the standby reports the last transaction log
|
||||
@ -311,8 +311,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
is shown here also, that is the order in which standbys will become
|
||||
the synchronous standby. The columns detailing what exactly the connection
|
||||
is doing are only visible if the user examining the view is a superuser.
|
||||
The client's hostname will be available only if
|
||||
<xref linkend="guc-log-hostname"> is set or if the user's hostname
|
||||
The client's host name will be available only if
|
||||
<xref linkend="guc-log-hostname"> is set or if the user's host name
|
||||
needed to be looked up during <filename>pg_hba.conf</filename>
|
||||
processing.
|
||||
</entry>
|
||||
|
@ -613,7 +613,7 @@ ERROR: could not serialize access due to read/write dependencies among transact
|
||||
with a SQLSTATE value of '40001'), because it will be very hard to
|
||||
predict exactly which transactions might contribute to the read/write
|
||||
dependencies and need to be rolled back to prevent serialization
|
||||
anomalies. The monitoring of read/write dependences has a cost, as does
|
||||
anomalies. The monitoring of read/write dependencies has a cost, as does
|
||||
the restart of transactions which are terminated with a serialization
|
||||
failure, but balanced against the cost and blocking involved in use of
|
||||
explicit locks and <literal>SELECT FOR UPDATE</> or <literal>SELECT FOR
|
||||
|
@ -440,14 +440,14 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
|
||||
the related Insert, Update, or Delete node, although time spent executing
|
||||
<literal>AFTER</> triggers is not. The time spent in each trigger
|
||||
(either <literal>BEFORE</> or <literal>AFTER</>) is also shown separately
|
||||
and is included in total runtime.
|
||||
and is included in total run time.
|
||||
Note, however, that deferred constraint triggers will not be executed
|
||||
until end of transaction and are thus not shown by
|
||||
<command>EXPLAIN ANALYZE</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are two significant ways in which runtimes measured by
|
||||
There are two significant ways in which run times measured by
|
||||
<command>EXPLAIN ANALYZE</command> can deviate from normal execution of
|
||||
the same query. First, since no output rows are delivered to the client,
|
||||
network transmission costs and I/O formatting costs are not included.
|
||||
|
@ -36,7 +36,7 @@ pg_test_fsync [options]
|
||||
<term><option>--filename</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the filename to write test data in.
|
||||
Specifies the file name to write test data in.
|
||||
This file should be in the same file system that the
|
||||
<filename>pg_xlog</> directory is or will be placed in.
|
||||
(<filename>pg_xlog</> contains the <acronym>WAL</> files.)
|
||||
|
@ -129,7 +129,7 @@ $$ LANGUAGE plperl;
|
||||
<note>
|
||||
<para>
|
||||
Arguments will be converted from the database's encoding to UTF-8
|
||||
for use inside plperl, and then converted from UTF-8 back to the
|
||||
for use inside PL/Perl, and then converted from UTF-8 back to the
|
||||
database encoding upon return.
|
||||
</para>
|
||||
</note>
|
||||
@ -786,7 +786,7 @@ SELECT release_hosts_query();
|
||||
<term><literal><function>encode_typed_literal(<replaceable>value</replaceable>, <replaceable>typename</replaceable>)</function></literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Converts a Perl variable to the value of the datatype passed as a
|
||||
Converts a Perl variable to the value of the data type passed as a
|
||||
second argument and returns a string representation of this value.
|
||||
Correctly handles nested arrays and values of composite types.
|
||||
</para>
|
||||
@ -1277,7 +1277,7 @@ DO 'elog(WARNING, join ", ", sort keys %INC)' language plperl;
|
||||
child processes.
|
||||
</para>
|
||||
<para>
|
||||
This parameter can only be set in the postgresql.conf file or on the server command line.
|
||||
This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -3586,7 +3586,7 @@ AFTER INSERT OR UPDATE OR DELETE ON emp
|
||||
<para>
|
||||
This example uses a trigger on the view to make it updatable, and
|
||||
ensure that any insert, update or delete of a row in the view is
|
||||
recorded (i.e., audited) in the emp_audit table. The current time
|
||||
recorded (i.e., audited) in the <literal>emp_audit</literal> table. The current time
|
||||
and user name are recorded, together with the type of operation
|
||||
performed, and the view displays the last modified time of each row.
|
||||
</para>
|
||||
|
@ -356,7 +356,7 @@ $$ LANGUAGE plpythonu;
|
||||
<para>
|
||||
When the PostgreSQL return type is <type>bytea</type>, the
|
||||
return value will be converted to a string (Python 2) or bytes
|
||||
(Python 3) using the respective Python builtins, with the
|
||||
(Python 3) using the respective Python built-ins, with the
|
||||
result being converted <type>bytea</type>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -365,7 +365,7 @@ $$ LANGUAGE plpythonu;
|
||||
<para>
|
||||
For all other PostgreSQL return types, the returned Python
|
||||
value is converted to a string using the Python
|
||||
builtin <literal>str</literal>, and the result is passed to the
|
||||
built-in <literal>str</literal>, and the result is passed to the
|
||||
input function of the PostgreSQL data type.
|
||||
</para>
|
||||
|
||||
@ -1101,7 +1101,7 @@ $$ LANGUAGE plpythonu;
|
||||
inserted into it. The subtransaction context manager does not
|
||||
trap errors, it only assures that all database operations executed
|
||||
inside its scope will be atomically committed or rolled back. A
|
||||
rollback of the subtransaction block occurrs on any kind of
|
||||
rollback of the subtransaction block occurs on any kind of
|
||||
exception exit, not only ones caused by errors originating from
|
||||
database access. A regular Python exception raised inside an
|
||||
explicit subtransaction block would also cause the subtransaction
|
||||
|
@ -1586,7 +1586,7 @@ GROUP BY region, product;
|
||||
<structname>top_regions</> and the output of <structname>top_regions</>
|
||||
is used in the primary <command>SELECT</> query.
|
||||
This example could have been written without <literal>WITH</>,
|
||||
but we'd have needed two levels of nested sub-SELECTs. It's a bit
|
||||
but we'd have needed two levels of nested sub-<command>SELECT</command>s. It's a bit
|
||||
easier to follow this way.
|
||||
</para>
|
||||
|
||||
|
@ -159,7 +159,7 @@ ALTER OPERATOR FAMILY <replaceable>name</replaceable> USING <replaceable class="
|
||||
<term><replaceable class="parameter">sort_family_name</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name (optionally schema-qualified) of an existing btree operator
|
||||
The name (optionally schema-qualified) of an existing <literal>btree</literal> operator
|
||||
family that describes the sort ordering associated with an ordering
|
||||
operator.
|
||||
</para>
|
||||
|
@ -128,7 +128,7 @@ CLUSTER [VERBOSE]
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<command>CLUSTER</> can re-sort the table using either an indexscan
|
||||
<command>CLUSTER</> can re-sort the table using either an index scan
|
||||
on the specified index, or (if the index is a b-tree) a sequential
|
||||
scan followed by sorting. It will attempt to choose the method that
|
||||
will be faster, based on planner cost parameters and available statistical
|
||||
@ -136,7 +136,7 @@ CLUSTER [VERBOSE]
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When an indexscan is used, a temporary copy of the table is created that
|
||||
When an index scan is used, a temporary copy of the table is created that
|
||||
contains the table data in the index order. Temporary copies of each
|
||||
index on the table are created as well. Therefore, you need free space on
|
||||
disk at least equal to the sum of the table size and the index sizes.
|
||||
@ -146,7 +146,7 @@ CLUSTER [VERBOSE]
|
||||
When a sequential scan and sort is used, a temporary sort file is
|
||||
also created, so that the peak temporary space requirement is as much
|
||||
as double the table size, plus the index sizes. This method is often
|
||||
faster than the indexscan method, but if the disk space requirement is
|
||||
faster than the index scan method, but if the disk space requirement is
|
||||
intolerable, you can disable this choice by temporarily setting <xref
|
||||
linkend="guc-enable-sort"> to <literal>off</>.
|
||||
</para>
|
||||
|
@ -184,7 +184,7 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
<term><replaceable class="parameter">sort_family_name</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name (optionally schema-qualified) of an existing btree operator
|
||||
The name (optionally schema-qualified) of an existing <literal>btree</literal> operator
|
||||
family that describes the sort ordering associated with an ordering
|
||||
operator.
|
||||
</para>
|
||||
|
@ -355,7 +355,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the optional boolean
|
||||
If the optional Boolean
|
||||
parameter <replaceable class="parameter">collatable</replaceable>
|
||||
is true, column definitions and expressions of the type may carry
|
||||
collation information through use of
|
||||
|
@ -143,7 +143,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Do not use indicators but instead use special values to represent
|
||||
NULLs. Historically there have been databases using this approach.
|
||||
null values. Historically there have been databases using this approach.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -152,7 +152,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Prepare all statements before using them. Libecpg will keep a cache of
|
||||
prepared statments and reuse a statement if it gets executed again. If the
|
||||
prepared statements and reuse a statement if it gets executed again. If the
|
||||
cache runs full, libecpg will free the least used statement.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -161,7 +161,7 @@ PostgreSQL documentation
|
||||
<term><option>questionmarks</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allow questionmark as placeholder for compatibility reasons.
|
||||
Allow question mark as placeholder for compatibility reasons.
|
||||
This used to be the default long ago.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -59,7 +59,7 @@ PostgreSQL documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There can be multiple pg_basebackups running at the same time, but it is
|
||||
There can be multiple <command>pg_basebackup</command>s running at the same time, but it is
|
||||
better from a performance point of view to take only one backup, and copy
|
||||
the result.
|
||||
</para>
|
||||
@ -127,7 +127,7 @@ PostgreSQL documentation
|
||||
Write the output as tar files in the target directory. The main
|
||||
data directory will be written to a file named
|
||||
<filename>base.tar</filename>, and all other tablespaces will
|
||||
be named after the tablespace oid.
|
||||
be named after the tablespace OID.
|
||||
</para>
|
||||
<para>
|
||||
If the value <literal>-</literal> (dash) is specified as
|
||||
@ -235,7 +235,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Enables verbose mode. Will output some extra steps during startup and
|
||||
shutdown, as well as show the exact filename that is currently being
|
||||
shutdown, as well as show the exact file name that is currently being
|
||||
processed if progress reporting is also enabled.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -142,7 +142,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Output commands to clean (drop)
|
||||
database objects prior to outputing the commands for creating them.
|
||||
database objects prior to outputting the commands for creating them.
|
||||
(Restore might generate some harmless errors.)
|
||||
</para>
|
||||
|
||||
|
@ -491,7 +491,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add client_hostname field to <link
|
||||
Add <structfield>client_hostname</structfield> field to <link
|
||||
linkend="monitoring-stats-views-table"><structname>pg_stat_activity</></link>
|
||||
(Peter Eisentraut)
|
||||
</para>
|
||||
@ -1227,7 +1227,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Make <command>EXPLAIN VERBOSE</> show the function call expression
|
||||
in a FunctionScan node (Tom Lane)
|
||||
in a <literal>FunctionScan</literal> node (Tom Lane)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1428,7 +1428,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These are used for xpath matching.
|
||||
These are used for XPath matching.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2046,7 +2046,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow ecpg to accept dynamic cursor names even in
|
||||
Allow ECPG to accept dynamic cursor names even in
|
||||
<literal>WHERE CURRENT OF</literal> clauses
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2139,7 +2139,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Enable building with the Mingw64 compiler (Andrew Dunstan)
|
||||
Enable building with the MinGW64 compiler (Andrew Dunstan)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -2175,7 +2175,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add missing get_{object}_oid() functions, for consistency
|
||||
Add missing <function>get_<replaceable>object</>_oid()</function> functions, for consistency
|
||||
(Robert Haas)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2316,7 +2316,7 @@
|
||||
<para>
|
||||
Allow <link
|
||||
linkend="fuzzystrmatch"><filename>contrib/fuzzystrmatch</></link>'s
|
||||
<function>levenshtein()</> function handle multi-byte characters
|
||||
<function>levenshtein()</> function handle multibyte characters
|
||||
(Alexander Korotkov)
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1662,7 +1662,7 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
||||
<userinput>/etc/rc.d/init.d/postgresql stop</userinput>
|
||||
</screen>
|
||||
See <xref linkend="runtime"> for details about starting and
|
||||
stoping the server.
|
||||
stopping the server.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
|
@ -26,7 +26,7 @@
|
||||
|
||||
<para>
|
||||
This module integrates with <productname>SELinux</> to provide an
|
||||
additional layer of security checking above and beyond what is normaly
|
||||
additional layer of security checking above and beyond what is normally
|
||||
provided by <productname>PostgreSQL</productname>. From the perspective of
|
||||
<productname>SELinux</>, this module allows
|
||||
<productname>PostgreSQL</productname> to function as a user-space object
|
||||
@ -97,7 +97,7 @@ Policy from config file: targeted
|
||||
<para>
|
||||
The following instructions that assume your installation is under the
|
||||
<filename>/usr/local/pgsql</> directory. Adjust the paths shown below as
|
||||
appropriate for your installaton.
|
||||
appropriate for your installation.
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
|
@ -343,7 +343,7 @@ WHERE t.author_id = p.person_id;
|
||||
|
||||
<para>
|
||||
The <function>xpath_table</> function assumes that the results of each XPath query
|
||||
might be multi-valued, so the number of rows returned by the function
|
||||
might be multivalued, so the number of rows returned by the function
|
||||
may not be the same as the number of input documents. The first row
|
||||
returned contains the first result from each query, the second row the
|
||||
second result from each query. If one of the queries has fewer values
|
||||
|
@ -227,7 +227,7 @@ gistbuildempty(PG_FUNCTION_ARGS)
|
||||
{
|
||||
ereport(ERROR,
|
||||
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
||||
errmsg("unlogged GIST indexes are not supported")));
|
||||
errmsg("unlogged GiST indexes are not supported")));
|
||||
|
||||
PG_RETURN_VOID();
|
||||
}
|
||||
@ -1405,7 +1405,7 @@ initGISTstate(GISTSTATE *giststate, Relation index)
|
||||
* functions don't care about collation, so we just do it
|
||||
* unconditionally. (We could alternatively call get_typcollation,
|
||||
* but that seems like expensive overkill --- there aren't going to be
|
||||
* any cases where a GIST storage type has a nondefault collation.)
|
||||
* any cases where a GiST storage type has a nondefault collation.)
|
||||
*/
|
||||
if (OidIsValid(index->rd_indcollation[i]))
|
||||
giststate->supportCollation[i] = index->rd_indcollation[i];
|
||||
|
@ -71,7 +71,7 @@ gistindex_keytest(IndexScanDesc scan,
|
||||
int i;
|
||||
|
||||
if (GistPageIsLeaf(page)) /* shouldn't happen */
|
||||
elog(ERROR, "invalid GIST tuple found on leaf page");
|
||||
elog(ERROR, "invalid GiST tuple found on leaf page");
|
||||
for (i = 0; i < scan->numberOfOrderBys; i++)
|
||||
so->distances[i] = -get_float8_infinity();
|
||||
return true;
|
||||
|
@ -306,7 +306,7 @@ gist_redo(XLogRecPtr lsn, XLogRecord *record)
|
||||
MemoryContext oldCxt;
|
||||
|
||||
/*
|
||||
* GIST indexes do not require any conflict processing. NB: If we ever
|
||||
* GiST indexes do not require any conflict processing. NB: If we ever
|
||||
* implement a similar optimization we have in b-tree, and remove killed
|
||||
* tuples outside VACUUM, we'll need to handle that here.
|
||||
*/
|
||||
|
@ -397,7 +397,7 @@ T052 MAX and MIN for row types NO
|
||||
T053 Explicit aliases for all-fields reference NO
|
||||
T061 UCS support NO
|
||||
T071 BIGINT data type YES
|
||||
T101 Enhanced nullability determiniation NO
|
||||
T101 Enhanced nullability determination NO
|
||||
T111 Updatable joins, unions, and columns NO
|
||||
T121 WITH (excluding RECURSIVE) in query expression YES
|
||||
T122 WITH (excluding RECURSIVE) in subquery YES
|
||||
|
@ -287,7 +287,7 @@ DefineIndex(RangeVar *heapRelation,
|
||||
{
|
||||
/*
|
||||
* Hack to provide more-or-less-transparent updating of old RTREE
|
||||
* indexes to GIST: if RTREE is requested and not found, use GIST.
|
||||
* indexes to GiST: if RTREE is requested and not found, use GIST.
|
||||
*/
|
||||
if (strcmp(accessMethodName, "rtree") == 0)
|
||||
{
|
||||
|
@ -1177,7 +1177,7 @@ WHERE p1.amprocfamily = p3.oid AND p3.opfmethod = p2.oid AND
|
||||
|
||||
-- Detect missing pg_amproc entries: should have as many support functions
|
||||
-- as AM expects for each datatype combination supported by the opfamily.
|
||||
-- GIST/GIN are special cases because each has an optional support function.
|
||||
-- GiST/GIN are special cases because each has an optional support function.
|
||||
SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
|
||||
FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
|
||||
WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
|
||||
@ -1190,7 +1190,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
|
||||
--------+---------+----------------+-----------------
|
||||
(0 rows)
|
||||
|
||||
-- Similar check for GIST/GIN, allowing one optional proc
|
||||
-- Similar check for GiST/GIN, allowing one optional proc
|
||||
SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
|
||||
FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
|
||||
WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
|
||||
@ -1205,7 +1205,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
|
||||
(0 rows)
|
||||
|
||||
-- Also, check if there are any pg_opclass entries that don't seem to have
|
||||
-- pg_amproc support. Again, GIST/GIN have to be checked specially.
|
||||
-- pg_amproc support. Again, GiST/GIN have to be checked specially.
|
||||
SELECT amname, opcname, count(*)
|
||||
FROM pg_am am JOIN pg_opclass op ON opcmethod = am.oid
|
||||
LEFT JOIN pg_amproc p ON amprocfamily = opcfamily AND
|
||||
|
@ -920,7 +920,7 @@ WHERE p1.amprocfamily = p3.oid AND p3.opfmethod = p2.oid AND
|
||||
|
||||
-- Detect missing pg_amproc entries: should have as many support functions
|
||||
-- as AM expects for each datatype combination supported by the opfamily.
|
||||
-- GIST/GIN are special cases because each has an optional support function.
|
||||
-- GiST/GIN are special cases because each has an optional support function.
|
||||
|
||||
SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
|
||||
FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
|
||||
@ -931,7 +931,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
|
||||
p4.amproclefttype = p3.amproclefttype AND
|
||||
p4.amprocrighttype = p3.amprocrighttype);
|
||||
|
||||
-- Similar check for GIST/GIN, allowing one optional proc
|
||||
-- Similar check for GiST/GIN, allowing one optional proc
|
||||
|
||||
SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
|
||||
FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
|
||||
@ -944,7 +944,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
|
||||
NOT IN (p1.amsupport, p1.amsupport - 1);
|
||||
|
||||
-- Also, check if there are any pg_opclass entries that don't seem to have
|
||||
-- pg_amproc support. Again, GIST/GIN have to be checked specially.
|
||||
-- pg_amproc support. Again, GiST/GIN have to be checked specially.
|
||||
|
||||
SELECT amname, opcname, count(*)
|
||||
FROM pg_am am JOIN pg_opclass op ON opcmethod = am.oid
|
||||
|
Loading…
Reference in New Issue
Block a user