Spell checking and markup refinement
This commit is contained in:
parent
0ee391b77a
commit
c13dc6402b
@ -819,7 +819,7 @@ SELECT pg_stop_backup();
|
||||
<function>pg_stop_backup()</> steps automatically, and transfers the
|
||||
backup over a regular <productname>PostgreSQL</productname> connection
|
||||
using the replication protocol, instead of requiring file system level
|
||||
access. pg_basebackup does not interfere with filesystem level backups
|
||||
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>
|
||||
|
@ -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;
|
||||
@ -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>
|
||||
|
@ -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>
|
||||
@ -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:
|
||||
|
@ -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,
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
@ -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…
x
Reference in New Issue
Block a user