mirror of
https://github.com/postgres/postgres.git
synced 2025-04-24 10:47:04 +03:00
Avoid extra whitespace in the arguments of <indexterm>.
As noted by Thom Brown, this confuses the DocBook index processor; it fails to merge entries that differ only in whitespace, and sorts them unexpectedly as well. Seems like a toolchain bug, but I'm not going to hold my breath waiting for a fix. Note: easiest way to find these is to look for double spaces in HTML.index.
This commit is contained in:
parent
8ad58279fa
commit
dca30da343
@ -1080,14 +1080,15 @@ su - postgres
|
||||
pointed to works correctly with <productname>PostgreSQL</>.
|
||||
</para>
|
||||
|
||||
<indexterm><primary>cross compilation</primary></indexterm>
|
||||
|
||||
<para>
|
||||
This option is mainly aimed at binary package distributors
|
||||
who know their target operating system well. The main
|
||||
advantage of using this option is that the PostgreSQL package
|
||||
won't need to be upgraded whenever any of the many local
|
||||
daylight-saving time rules change. Another advantage is that
|
||||
PostgreSQL can be cross-compiled<indexterm><primary>cross
|
||||
compilation</primary></indexterm> more straightforwardly if the
|
||||
PostgreSQL can be cross-compiled more straightforwardly if the
|
||||
time zone database files do not need to be built during the
|
||||
installation.
|
||||
</para>
|
||||
|
@ -188,7 +188,7 @@ PGconn *PQconnectdbParams(const char **keywords, const char **values, int expand
|
||||
the value for <literal>hostaddr</> gives the server network address.
|
||||
The value for <literal>host</> is ignored unless the
|
||||
authentication method requires it, in which case it will be
|
||||
used as the host name.
|
||||
used as the host name.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -1610,10 +1610,12 @@ int PQsocket(const PGconn *conn);
|
||||
<term><function>PQbackendPID</function><indexterm><primary>PQbackendPID</></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the process <acronym>ID</acronym>
|
||||
(PID)<indexterm><primary>PID</><secondary>determining PID of
|
||||
server process</><tertiary>in libpq</></> of the backend
|
||||
process handling this connection.
|
||||
Returns the process <acronym>ID</acronym> (PID)<indexterm>
|
||||
<primary>PID</>
|
||||
<secondary>determining PID of server process</>
|
||||
<tertiary>in libpq</>
|
||||
</indexterm>
|
||||
of the backend process handling this connection.
|
||||
|
||||
<synopsis>
|
||||
int PQbackendPID(const PGconn *conn);
|
||||
@ -4201,7 +4203,7 @@ int PQcancel(PGcancel *cancel, char *errbuf, int errbufsize);
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQrequestCancel</function> is a deprecated variant of
|
||||
<function>PQcancel</function>.
|
||||
<function>PQcancel</function>.
|
||||
<synopsis>
|
||||
int PQrequestCancel(PGconn *conn);
|
||||
</synopsis>
|
||||
@ -5459,12 +5461,12 @@ int PQlibVersion(void);
|
||||
|
||||
<para>
|
||||
The function <function>PQsetNoticeReceiver</function>
|
||||
<indexterm><primary>notice
|
||||
receiver</></><indexterm><primary>PQsetNoticeReceiver</></> sets or
|
||||
<indexterm><primary>notice receiver</></>
|
||||
<indexterm><primary>PQsetNoticeReceiver</></> sets or
|
||||
examines the current notice receiver for a connection object.
|
||||
Similarly, <function>PQsetNoticeProcessor</function>
|
||||
<indexterm><primary>notice
|
||||
processor</></><indexterm><primary>PQsetNoticeProcessor</></> sets or
|
||||
<indexterm><primary>notice processor</></>
|
||||
<indexterm><primary>PQsetNoticeProcessor</></> sets or
|
||||
examines the current notice processor.
|
||||
|
||||
<synopsis>
|
||||
|
@ -78,6 +78,8 @@ SELECT datname FROM pg_database;
|
||||
<sect1 id="manage-ag-createdb">
|
||||
<title>Creating a Database</title>
|
||||
|
||||
<indexterm><primary>CREATE DATABASE</></>
|
||||
|
||||
<para>
|
||||
In order to create a database, the <productname>PostgreSQL</>
|
||||
server must be up and running (see <xref
|
||||
@ -86,8 +88,7 @@ SELECT datname FROM pg_database;
|
||||
|
||||
<para>
|
||||
Databases are created with the SQL command
|
||||
<xref linkend="sql-createdatabase">:<indexterm><primary>CREATE
|
||||
DATABASE</></>
|
||||
<xref linkend="sql-createdatabase">:
|
||||
<synopsis>
|
||||
CREATE DATABASE <replaceable>name</>;
|
||||
</synopsis>
|
||||
|
@ -3983,13 +3983,16 @@ $$ LANGUAGE plpgsql;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>preparing a query</>
|
||||
<secondary>in PL/pgSQL</>
|
||||
</indexterm>
|
||||
As each expression and <acronym>SQL</acronym> command is first
|
||||
executed in the function, the <application>PL/pgSQL</> interpreter
|
||||
creates a prepared execution plan (using the
|
||||
<acronym>SPI</acronym> manager's <function>SPI_prepare</function>
|
||||
and <function>SPI_saveplan</function>
|
||||
functions).<indexterm><primary>preparing a query</><secondary>in
|
||||
PL/pgSQL</></> Subsequent visits to that expression or command
|
||||
and <function>SPI_saveplan</function> functions).
|
||||
Subsequent visits to that expression or command
|
||||
reuse the prepared plan. Thus, a function with conditional code
|
||||
that contains many statements for which execution plans might be
|
||||
required will only prepare and save those plans that are really
|
||||
|
@ -398,7 +398,7 @@ $$ LANGUAGE plpythonu;
|
||||
<title>Null, None</title>
|
||||
<para>
|
||||
If an SQL null value<indexterm><primary>null value</primary><secondary
|
||||
sortas="PL/Python">PL/Python</secondary></indexterm> is passed to a
|
||||
sortas="PL/Python">in PL/Python</secondary></indexterm> is passed to a
|
||||
function, the argument value will appear as <symbol>None</symbol> in
|
||||
Python. The above function definition will return the wrong answer for null
|
||||
inputs. We could add <literal>STRICT</literal> to the function definition
|
||||
@ -716,8 +716,8 @@ SELECT * FROM multiout_simple_setof(3);
|
||||
data between function calls. This variable is private static data.
|
||||
The global dictionary <varname>GD</varname> is public data,
|
||||
available to all Python functions within a session. Use with
|
||||
care.<indexterm><primary>global data</><secondary>in
|
||||
PL/Python</></indexterm>
|
||||
care.<indexterm><primary>global data</>
|
||||
<secondary>in PL/Python</></indexterm>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -344,8 +344,8 @@ spi_exec -array C "SELECT * FROM pg_class" {
|
||||
<para>
|
||||
Prepares and saves a query plan for later execution. The
|
||||
saved plan will be retained for the life of the current
|
||||
session.<indexterm><primary>preparing a query</><secondary>in
|
||||
PL/Tcl</></>
|
||||
session.<indexterm><primary>preparing a query</>
|
||||
<secondary>in PL/Tcl</></>
|
||||
</para>
|
||||
<para>
|
||||
The query can use parameters, that is, placeholders for
|
||||
|
@ -895,16 +895,16 @@ SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
|
||||
all sales of the product.
|
||||
</para>
|
||||
|
||||
<indexterm><primary>functional dependency</primary></indexterm>
|
||||
|
||||
<para>
|
||||
If the products table is set up so that,
|
||||
say, <literal>product_id</literal> is the primary key, then it
|
||||
would be enough to group by <literal>product_id</literal> in the
|
||||
above example, since name and price would
|
||||
be <firstterm>functionally
|
||||
dependent</firstterm><indexterm><primary>functional
|
||||
dependency</primary></indexterm> on the product ID, and so there
|
||||
would be no ambiguity about which name and price value to return
|
||||
for each product ID group.
|
||||
If the products table is set up so that, say,
|
||||
<literal>product_id</literal> is the primary key, then it would be
|
||||
enough to group by <literal>product_id</literal> in the above example,
|
||||
since name and price would be <firstterm>functionally
|
||||
dependent</firstterm> on the product ID, and so there would be no
|
||||
ambiguity about which name and price value to return for each product
|
||||
ID group.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1170,9 +1170,12 @@ SELECT DISTINCT <replaceable>select_list</replaceable> ...
|
||||
can be used to specify the default behavior of retaining all rows.)
|
||||
</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>null value</>
|
||||
<secondary sortas="DISTINCT">in DISTINCT</>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>null value</><secondary sortas="DISTINCT">in
|
||||
DISTINCT</></indexterm>
|
||||
Obviously, two rows are considered distinct if they differ in at
|
||||
least one column value. Null values are considered equal in this
|
||||
comparison.
|
||||
|
@ -142,8 +142,11 @@ postgres$ <userinput>initdb -D /usr/local/pgsql/data</userinput>
|
||||
trust other local users, we recommend you use one of
|
||||
<command>initdb</command>'s <option>-W</option>, <option>--pwprompt</option>
|
||||
or <option>--pwfile</option> options to assign a password to the
|
||||
database superuser.<indexterm><primary>password</><secondary>of the
|
||||
superuser</></indexterm> Also, specify <option>-A md5</> or
|
||||
database superuser.<indexterm>
|
||||
<primary>password</>
|
||||
<secondary>of the superuser</>
|
||||
</indexterm>
|
||||
Also, specify <option>-A md5</> or
|
||||
<option>-A password</> so that the default <literal>trust</> authentication
|
||||
mode is not used; or modify the generated <filename>pg_hba.conf</filename>
|
||||
file after running <command>initdb</command>, but
|
||||
@ -264,8 +267,11 @@ pg_ctl start -l logfile
|
||||
|
||||
<para>
|
||||
Normally, you will want to start the database server when the
|
||||
computer boots.<indexterm><primary>booting</><secondary>starting
|
||||
the server during</></> Autostart scripts are operating-system-specific.
|
||||
computer boots.<indexterm>
|
||||
<primary>booting</>
|
||||
<secondary>starting the server during</>
|
||||
</indexterm>
|
||||
Autostart scripts are operating-system-specific.
|
||||
There are a few distributed with
|
||||
<productname>PostgreSQL</productname> in the
|
||||
<filename>contrib/start-scripts</> directory. Installing one will require
|
||||
|
@ -3188,9 +3188,12 @@ char * SPI_getnspname(Relation <parameter>rel</parameter>)
|
||||
<title>Memory Management</title>
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>memory context</primary>
|
||||
<secondary>in SPI</secondary>
|
||||
</indexterm>
|
||||
<productname>PostgreSQL</productname> allocates memory within
|
||||
<firstterm>memory contexts</firstterm><indexterm><primary>memory
|
||||
context</primary><secondary>in SPI</secondary></indexterm>, which provide a convenient method of
|
||||
<firstterm>memory contexts</firstterm>, which provide a convenient method of
|
||||
managing allocations made in many different places that need to
|
||||
live for differing amounts of time. Destroying a context releases
|
||||
all the memory that was allocated in it. Thus, it is not necessary
|
||||
|
@ -189,9 +189,13 @@ UPDATE "my_table" SET "a" = 5;
|
||||
ampersands. The length limitation still applies.
|
||||
</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>Unicode escape</primary>
|
||||
<secondary>in identifiers</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>Unicode escape</primary><secondary>in
|
||||
identifiers</secondary></indexterm> A variant of quoted
|
||||
A variant of quoted
|
||||
identifiers allows including escaped Unicode characters identified
|
||||
by their code points. This variant starts
|
||||
with <literal>U&</literal> (upper or lower case U followed by
|
||||
|
@ -242,9 +242,12 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>trigger</>
|
||||
<secondary>arguments for trigger functions</>
|
||||
</indexterm>
|
||||
When a trigger is being defined, arguments can be specified for
|
||||
it.<indexterm><primary>trigger</><secondary>arguments for trigger
|
||||
functions</></indexterm> The purpose of including arguments in the
|
||||
it. The purpose of including arguments in the
|
||||
trigger definition is to allow different triggers with similar
|
||||
requirements to call the same function. As an example, there
|
||||
could be a generalized trigger function that takes as its
|
||||
|
@ -32,10 +32,7 @@
|
||||
<indexterm>
|
||||
<primary>output function</primary>
|
||||
</indexterm>
|
||||
A user-defined type must always have input and output
|
||||
functions.<indexterm><primary>input function</primary><secondary>of
|
||||
a data type</secondary></indexterm><indexterm><primary>output
|
||||
function</primary><secondary>of a data type</secondary></indexterm>
|
||||
A user-defined type must always have input and output functions.
|
||||
These functions determine how the type appears in strings (for input
|
||||
by the user and output to the user) and how the type is organized in
|
||||
memory. The input function takes a null-terminated character string
|
||||
@ -218,11 +215,13 @@ CREATE TYPE complex (
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>array</primary>
|
||||
<secondary>of user-defined type</secondary>
|
||||
</indexterm>
|
||||
When you define a new base type,
|
||||
<productname>PostgreSQL</productname> automatically provides support
|
||||
for arrays of that
|
||||
type.<indexterm><primary>array</primary><secondary>of user-defined
|
||||
type</secondary></indexterm> The array type typically
|
||||
for arrays of that type. The array type typically
|
||||
has the same name as the base type with the underscore character
|
||||
(<literal>_</>) prepended.
|
||||
</para>
|
||||
|
Loading…
x
Reference in New Issue
Block a user