mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-15 08:20:16 +08:00
Merge some user-submitted suggestions for improvement into the
documentation. Mostly add some <xref>s, fix a few typos, and document that zlib is required in the installation docs.
This commit is contained in:
Neil Conway
parent
1b5cd6dcdc
commit
1d2e0e6d3e
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.161 2005/10/14 11:47:56 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.162 2005/10/15 01:47:11 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
@ -15,10 +15,10 @@ $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.161 2005/10/14 11:47:56 momjia
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> has a rich set of native data
|
||||
types available to users.
|
||||
Users may add new types to <productname>PostgreSQL</productname> using the
|
||||
<command>CREATE TYPE</command> command.
|
||||
<productname>PostgreSQL</productname> has a rich set of native data
|
||||
types available to users. Users may add new types to
|
||||
<productname>PostgreSQL</productname> using the <xref
|
||||
linkend="sql-createtype" endterm="sql-createtype-title"> command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.29 2004/12/30 03:13:56 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.30 2005/10/15 01:47:11 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="extend">
|
||||
@ -131,12 +131,14 @@ $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.29 2004/12/30 03:13:56 tgl Exp $
|
||||
|
||||
<para>
|
||||
Composite types, or row types, are created whenever the user
|
||||
creates a table; it's also possible to define a
|
||||
<quote>stand-alone</> composite type with no associated table. A
|
||||
composite type is simply a list of base types with associated
|
||||
field names. A value of a composite type is a row or record of
|
||||
field values. The user can access the component fields from
|
||||
<acronym>SQL</> queries.
|
||||
creates a table. It is also possible to use <xref
|
||||
linkend="sql-createtype" endterm="sql-createtype-title"> to
|
||||
define a <quote>stand-alone</> composite type with no associated
|
||||
table. A composite type is simply a list of types with
|
||||
associated field names. A value of a composite type is a row or
|
||||
record of field values. The user can access the component fields
|
||||
from <acronym>SQL</> queries. Refer to <xref linkend="rowtypes">
|
||||
for more information on composite types.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.241 2005/07/20 23:57:46 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.242 2005/10/15 01:47:11 neilc Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
@ -94,9 +94,9 @@ su - postgres
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<application>gzip</> is needed to unpack the distribution in the
|
||||
first place.<![%standalone-include;[ If you are reading this, you probably already got
|
||||
past that hurdle.]]>
|
||||
<application>tar</> is required to unpack the source
|
||||
distribution in the first place, in addition to either
|
||||
<application>gzip</> or <application>bzip2</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -120,6 +120,21 @@ su - postgres
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>zlib</primary>
|
||||
</indexterm>
|
||||
|
||||
The <productname>zlib</productname> compression library will be
|
||||
used by default. If you don't want to use it then you must
|
||||
specify the <option>--without-zlib</option> option for
|
||||
<filename>configure</filename>. Using this option disables
|
||||
support for compressed archives in <application>pg_dump</> and
|
||||
<application>pg_restore</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<indexterm>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.77 2005/10/06 20:51:20 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.78 2005/10/15 01:47:11 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
@ -963,16 +963,17 @@ $$ LANGUAGE plpgsql;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the case of <function>logfunc1</function>, the
|
||||
<productname>PostgreSQL</productname> main parser knows when
|
||||
preparing the plan for the <command>INSERT</command>, that the string
|
||||
<literal>'now'</literal> should be interpreted as
|
||||
<type>timestamp</type> because the target column of <classname>logtable</classname>
|
||||
is of that type. Thus, it will make a constant from it at this
|
||||
time and this constant value is then used in all invocations of
|
||||
<function>logfunc1</function> during the lifetime of the
|
||||
session. Needless to say that this isn't what the
|
||||
programmer wanted.
|
||||
In the case of <function>logfunc1</function>, the
|
||||
<productname>PostgreSQL</productname> main parser knows when
|
||||
preparing the plan for the <command>INSERT</command> that the
|
||||
string <literal>'now'</literal> should be interpreted as
|
||||
<type>timestamp</type> because the target column of
|
||||
<classname>logtable</classname> is of that type. Thus,
|
||||
<literal>'now'</literal> will be converted to a constant when the
|
||||
<command>INSERT</command> is planned, and then used in all
|
||||
invocations of <function>logfunc1</function> during the lifetime
|
||||
of the session. Needless to say, this isn't what the programmer
|
||||
wanted.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -985,7 +986,7 @@ $$ LANGUAGE plpgsql;
|
||||
<application>PL/pgSQL</application> interpreter casts this
|
||||
string to the <type>timestamp</type> type by calling the
|
||||
<function>text_out</function> and <function>timestamp_in</function>
|
||||
functions for the conversion. So, the computed time stamp is updated
|
||||
functions for the conversion. So, the computed timestamp is updated
|
||||
on each execution as the programmer expects.
|
||||
</para>
|
||||
|
||||
@ -1452,8 +1453,8 @@ GET DIAGNOSTICS integer_var = ROW_COUNT;
|
||||
</itemizedlist>
|
||||
|
||||
<literal>FOUND</literal> is a local variable within each
|
||||
<application>PL/pgSQL</application> function; so any changes
|
||||
to it affect only the current function.
|
||||
<application>PL/pgSQL</application> function; any changes to it
|
||||
affect only the current function.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/prepare.sgml,v 1.15 2004/10/29 19:40:33 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/prepare.sgml,v 1.16 2005/10/15 01:47:12 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -63,7 +63,8 @@ PREPARE <replaceable class="PARAMETER">plan_name</replaceable> [ (<replaceable c
|
||||
also means that a single prepared statement cannot be used by
|
||||
multiple simultaneous database clients; however, each client can create
|
||||
their own prepared statement to use. The prepared statement can be
|
||||
manually cleaned up using the <command>DEALLOCATE</> command.
|
||||
manually cleaned up using the <xref linkend="sql-deallocate"
|
||||
endterm="sql-deallocate-title"> command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.105 2005/10/14 20:48:18 adunstan Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.106 2005/10/15 01:47:12 neilc Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xfunc">
|
||||
@ -881,9 +881,9 @@ CREATE FUNCTION test(int, int) RETURNS int
|
||||
Every function has a <firstterm>volatility</> classification, with
|
||||
the possibilities being <literal>VOLATILE</>, <literal>STABLE</>, or
|
||||
<literal>IMMUTABLE</>. <literal>VOLATILE</> is the default if the
|
||||
<command>CREATE FUNCTION</command> command does not specify a category.
|
||||
The volatility category is a promise to the optimizer about the behavior
|
||||
of the function:
|
||||
<xref linkend="sql-createfunction" endterm="sql-createfunction-title">
|
||||
command does not specify a category. The volatility category is a
|
||||
promise to the optimizer about the behavior of the function:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -1180,8 +1180,9 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
file is retained in memory. Future calls in the same session to
|
||||
the function(s) in that file will only incur the small overhead of
|
||||
a symbol table lookup. If you need to force a reload of an object
|
||||
file, for example after recompiling it, use the <command>LOAD</>
|
||||
command or begin a fresh session.
|
||||
file, for example after recompiling it, use the <xref
|
||||
linkend="sql-load" endterm="sql-load-title"> command or begin a
|
||||
fresh session.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1652,7 +1653,7 @@ CREATE FUNCTION copytext(text) RETURNS text
|
||||
LANGUAGE C STRICT;
|
||||
|
||||
CREATE FUNCTION concat_text(text, text) RETURNS text
|
||||
AS '<replaceable>DIRECTORY</replaceable>/funcs', 'concat_text',
|
||||
AS '<replaceable>DIRECTORY</replaceable>/funcs', 'concat_text'
|
||||
LANGUAGE C STRICT;
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user