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