mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-11-21 03:13:05 +08:00
Grammatical and spelling fixes.
This commit is contained in:
Tom Lane
parent
5590d5fe99
commit
5e86d226e4
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.14 2001/11/19 03:58:23 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.15 2001/11/19 09:05:00 tgl Exp $ -->
|
||||
|
||||
<chapter id="arrays">
|
||||
<title>Arrays</title>
|
||||
@ -20,7 +20,7 @@ CREATE TABLE sal_emp (
|
||||
);
|
||||
</programlisting>
|
||||
As shown, an array data type is named by appending square brackets
|
||||
(<literal>[ ]</>) to the data type name of the array elements.
|
||||
(<literal>[]</>) to the data type name of the array elements.
|
||||
The above query will create a table named
|
||||
<structname>sal_emp</structname> with a <type>text</type> string
|
||||
(<structfield>name</structfield>), a one-dimensional array of type
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.71 2001/11/19 09:05:00 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
@ -23,15 +23,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tg
|
||||
|
||||
<para>
|
||||
<xref linkend="datatype-table"> shows all general-purpose data types
|
||||
available to users. Most of the alternative names listed in the
|
||||
included in the standard distribution. Most of the alternative names
|
||||
listed in the
|
||||
<quote>Aliases</quote> column are the names used internally by
|
||||
<productname>Postgres</productname> for historical reasons. In
|
||||
addition, some internally used or deprecated types are available,
|
||||
but they are not documented here. Many of the built-in types have
|
||||
obvious external formats. However, several types are either unique
|
||||
to <productname>Postgres</productname>, such as open and closed
|
||||
paths, or have several possibilities for formats, such as the date
|
||||
and time types.
|
||||
but they are not listed here.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -242,7 +239,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tg
|
||||
<row>
|
||||
<entry><type>timestamp [ with time zone ]</type></entry>
|
||||
<entry>timestamptz</entry>
|
||||
<entry>date and time</entry>
|
||||
<entry>date and time, including time zone</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -264,9 +261,21 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tg
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Each data type has an external representation determined by its input
|
||||
and output functions. Many of the built-in types have
|
||||
obvious external formats. However, several types are either unique
|
||||
to <productname>Postgres</productname>, such as open and closed
|
||||
paths, or have several possibilities for formats, such as the date
|
||||
and time types.
|
||||
Most of the input and output functions corresponding to the
|
||||
base types (e.g., integers and floating point numbers) do some
|
||||
error-checking.
|
||||
Some of the input and output functions are not invertible. That is,
|
||||
the result of an output function may lose precision when compared to
|
||||
the original input.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some of the operators and functions (e.g.,
|
||||
addition and multiplication) do not perform run-time error-checking in the
|
||||
interests of improving execution speed.
|
||||
@ -274,12 +283,6 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tg
|
||||
silently underflow or overflow.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some of the input and output functions are not invertible. That is,
|
||||
the result of an output function may lose precision when compared to
|
||||
the original input.
|
||||
</para>
|
||||
|
||||
<sect1 id="datatype-numeric">
|
||||
<title>Numeric Types</title>
|
||||
|
||||
@ -465,6 +468,14 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tg
|
||||
platform where this is actually the case.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
SQL only specifies the integer types <type>integer</type> (or
|
||||
<type>int</type>) and <type>smallint</type>. The type
|
||||
<type>bigint</type>, and the type names <type>int2</type>,
|
||||
<type>int4</type>, and <type>int8</type> are extensions, which
|
||||
are shared with various other RDBMS products.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you have a column of type <type>smallint</type> or
|
||||
@ -475,25 +486,17 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.70 2001/11/19 03:58:22 tg
|
||||
... WHERE smallint_column = 42
|
||||
</programlisting>
|
||||
will not use an index, because the system assigns type
|
||||
<type>integer</type> to the 42, and PostgreSQL currently cannot
|
||||
use an index when two different data types are involved. A
|
||||
<type>integer</type> to the constant 42, and PostgreSQL currently
|
||||
cannot use an index when two different data types are involved. A
|
||||
workaround is to single-quote the constant, thus:
|
||||
<programlisting>
|
||||
... WHERE smallint_column = '42'
|
||||
</programlisting>
|
||||
This will cause the system to delay the type resolution and will
|
||||
This will cause the system to delay type resolution and will
|
||||
assign the right type to the constant.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
SQL only specifies the integer types <type>integer</type> (or
|
||||
<type>int</type>) and <type>smallint</type>. The type
|
||||
<type>bigint</type>, and the type names <type>int2</type>,
|
||||
<type>int4</type>, and <type>int8</type> are extensions, which
|
||||
are shared with various other RDBMS products.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="datatype-numeric-decimal">
|
||||
@ -609,9 +612,9 @@ NUMERIC
|
||||
|
||||
<para>
|
||||
Normally, the <type>real</type> type has a range of at least
|
||||
-1E+37 to +1E+37 with a precision of at least 6. The
|
||||
-1E+37 to +1E+37 with a precision of at least 6 decimal digits. The
|
||||
<type>double precision</type> type normally has a range of around
|
||||
-1E+308 to +1E+308 with a precision of at least 15. Values that
|
||||
-1E+308 to +1E+308 with a precision of at least 15 digits. Values that
|
||||
are too large or too small will cause an error. Rounding may
|
||||
take place if the precision of an input number is too high.
|
||||
Numbers too close to zero that are not representable as distinct
|
||||
@ -1553,13 +1556,13 @@ January 8 04:05:06 1999 PST
|
||||
or abbreviations or plurals of these units;
|
||||
<literal>Direction</literal> can be <literal>ago</literal> or
|
||||
empty. The at sign (<literal>@</>) is optional noise. The amounts
|
||||
of different quantities are implicitly added up with appropriate
|
||||
of different units are implicitly added up with appropriate
|
||||
sign accounting.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Quantities of days, hours, minutes, and seconds can be specified without
|
||||
explicit unit markings: for example, <literal>'1 12:59:10'</> is read
|
||||
explicit unit markings. For example, <literal>'1 12:59:10'</> is read
|
||||
the same as <literal>'1 day 12 hours 59 min 10 sec'</>.
|
||||
</para>
|
||||
</sect3>
|
||||
@ -1637,10 +1640,6 @@ January 8 04:05:06 1999 PST
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
<literal>'now'</literal> is resolved when the value is inserted, <literal>'current'</literal>
|
||||
is resolved every time the value is retrieved. So you probably want to use <literal>'now'</literal>
|
||||
in most applications. (Of course you <emphasis>really</emphasis> want to use
|
||||
<literal>CURRENT_TIMESTAMP</literal>, which is equivalent to <literal>'now'</literal>.)
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
@ -1705,7 +1704,7 @@ January 8 04:05:06 1999 PST
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The output of the <type>date</type> and <type>time</type> styles is of course
|
||||
The output of the <type>date</type> and <type>time</type> types is of course
|
||||
only the date or time part in accordance with the above examples.
|
||||
</para>
|
||||
|
||||
@ -1794,7 +1793,7 @@ January 8 04:05:06 1999 PST
|
||||
<para>
|
||||
Although the <type>date</type> type
|
||||
does not have an associated time zone, the
|
||||
<type>time</type> type can or does.
|
||||
<type>time</type> type can.
|
||||
Time zones in the real world can have no meaning unless
|
||||
associated with a date as well as a time
|
||||
since the offset may vary through the year with daylight savings
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.81 2001/11/19 03:58:23 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.82 2001/11/19 09:05:01 tgl Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -31,7 +31,7 @@ Postgres documentation
|
||||
and some explicitly marked functions, are not specified by the <acronym>SQL</acronym>
|
||||
standard. Some of this extended functionality is present in other
|
||||
<acronym>RDBMS</acronym> products, and in many cases this
|
||||
functionality is compatible and consistant between various products.
|
||||
functionality is compatible and consistent between various products.
|
||||
</para>
|
||||
|
||||
|
||||
@ -697,8 +697,8 @@ Postgres documentation
|
||||
Functions returning a <type>numeric</type> result take
|
||||
<type>numeric</type> input arguments, unless otherwise specified.
|
||||
Many of these functions are implemented on top
|
||||
of the host system's C library and behavior in boundary cases could
|
||||
therefore vary depending on the operating system.
|
||||
of the host system's C library; accuracy and behavior in boundary cases
|
||||
could therefore vary depending on the host system.
|
||||
</para>
|
||||
|
||||
<table>
|
||||
@ -828,7 +828,7 @@ Postgres documentation
|
||||
<entry><function>char_length</function>(<parameter>string</parameter>) or <function>character_length</function>(<parameter>string</parameter>)</entry>
|
||||
<entry><type>integer</type></entry>
|
||||
<entry>
|
||||
length of string
|
||||
number of characters in string
|
||||
<indexterm>
|
||||
<primary>character strings</primary>
|
||||
<secondary>length</secondary>
|
||||
@ -892,7 +892,7 @@ Postgres documentation
|
||||
<parameter>characters</parameter> (a space by default) from the
|
||||
beginning/end/both ends of the <parameter>string</parameter>.
|
||||
</entry>
|
||||
<entry><literal>trim(both 'x' from 'xTomx')</literal></entry>
|
||||
<entry><literal>trim(both 'x' from 'xTomxx')</literal></entry>
|
||||
<entry><literal>Tom</literal></entry>
|
||||
</row>
|
||||
|
||||
@ -910,7 +910,7 @@ Postgres documentation
|
||||
<para>
|
||||
Additional string manipulation functions are available and are
|
||||
listed below. Some of them are used internally to implement the
|
||||
<acronym>SQL</acronym> string functions listed above.
|
||||
<acronym>SQL</acronym>-standard string functions listed above.
|
||||
</para>
|
||||
|
||||
<table id="functions-string-other">
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.26 2001/11/18 00:59:00 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.27 2001/11/19 09:05:01 tgl Exp $ -->
|
||||
|
||||
<chapter id="indexes">
|
||||
<title id="indexes-title">Indexes</title>
|
||||
@ -83,10 +83,9 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Indexes can also benefit <command>UPDATE</command>s and
|
||||
<command>DELETE</command>s with search conditions. Note that a
|
||||
query or data manipulation commands can only use at most one index
|
||||
per table. Indexes can also be used in table join methods. Thus,
|
||||
Indexes can benefit <command>UPDATE</command>s and
|
||||
<command>DELETE</command>s with search conditions. Indexes can also be
|
||||
used in join queries. Thus,
|
||||
an index defined on a column that is part of a join condition can
|
||||
significantly speed up queries with joins.
|
||||
</para>
|
||||
@ -95,7 +94,9 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
When an index is created, it has to be kept synchronized with the
|
||||
table. This adds overhead to data manipulation operations.
|
||||
Therefore indexes that are non-essential or do not get used at all
|
||||
should be removed.
|
||||
should be removed. Note that a
|
||||
query or data manipulation command can use at most one index
|
||||
per table.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -140,7 +141,7 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
<primary>R-tree</primary>
|
||||
<see>indexes</see>
|
||||
</indexterm>
|
||||
R-tree indexes are especially suited for spacial data. To create
|
||||
R-tree indexes are especially suited for spatial data. To create
|
||||
an R-tree index, use a command of the form
|
||||
<synopsis>
|
||||
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING RTREE (<replaceable>column</replaceable>);
|
||||
@ -221,7 +222,7 @@ CREATE TABLE test2 (
|
||||
name varchar
|
||||
);
|
||||
</programlisting>
|
||||
(Say, you keep you your <filename class="directory">/dev</filename>
|
||||
(Say, you keep your <filename class="directory">/dev</filename>
|
||||
directory in a database...) and you frequently make queries like
|
||||
<programlisting>
|
||||
SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> AND minor = <replaceable>constant</replaceable>;
|
||||
@ -337,11 +338,11 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
|
||||
|
||||
<para>
|
||||
For example, a common way to do case-insensitive comparisons is to
|
||||
use the <function>lower</function>:
|
||||
use the <function>lower</function> function:
|
||||
<programlisting>
|
||||
SELECT * FROM test1 WHERE lower(col1) = 'value';
|
||||
</programlisting>
|
||||
In order for that query to be able to use an index, it has to be
|
||||
This query can use an index, if one has been
|
||||
defined on the result of the <literal>lower(column)</literal>
|
||||
operation:
|
||||
<programlisting>
|
||||
@ -360,8 +361,8 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
|
||||
<tip>
|
||||
<para>
|
||||
The restrictions mentioned in the previous paragraph can easily be
|
||||
worked around by defining custom functions to use in the index
|
||||
definition that call the desired function(s) internally.
|
||||
worked around by defining a custom function to use in the index
|
||||
definition that computes any desired result internally.
|
||||
</para>
|
||||
</tip>
|
||||
</sect1>
|
||||
@ -600,7 +601,8 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
A <firstterm>partial index</firstterm> is an index built over a
|
||||
subset of a table; the subset is defined by a conditional
|
||||
expression (called the <firstterm>predicate</firstterm> of the
|
||||
partial index).
|
||||
partial index). The index contains entries for only those table
|
||||
rows that satisfy the predicate.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -608,8 +610,8 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
values. Since a query conditionalized on a common value will not
|
||||
use the index anyway, there is no point in keeping those rows in the
|
||||
index at all. This reduces the size of the index, which will speed
|
||||
up queries that do use the index. It will also speed up many data
|
||||
manipulation operations because the index does not need to be
|
||||
up queries that do use the index. It will also speed up many table
|
||||
update operations because the index does not need to be
|
||||
updated in all cases. <xref linkend="indexes-partial-ex1"> shows a
|
||||
possible application of this idea.
|
||||
</para>
|
||||
@ -766,7 +768,7 @@ SELECT * FROM orders WHERE order_nr = 3501;
|
||||
|
||||
<para>
|
||||
Although indexes in <productname>PostgreSQL</> do not need
|
||||
maintenance and tuning, it is still important that it is checked
|
||||
maintenance and tuning, it is still important to check
|
||||
which indexes are actually used by the real-life query workload.
|
||||
Examining index usage is done with the <command>EXPLAIN</> command;
|
||||
its application for this purpose is illustrated in <xref
|
||||
@ -863,7 +865,7 @@ SELECT * FROM orders WHERE order_nr = 3501;
|
||||
|
||||
<para>
|
||||
If you do not succeed in adjusting the costs to be more
|
||||
appropriate, then you may have to do with forcing index usage
|
||||
appropriate, then you may have to resort to forcing index usage
|
||||
explicitly. You may also want to contact the
|
||||
<productname>PostgreSQL</> developers to examine the issue.
|
||||
</para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.50 2001/11/08 23:34:33 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.51 2001/11/19 09:05:01 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -743,8 +743,8 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
Transaction identifiers are 32-bit quantities. In a long-lived
|
||||
database it is possible for transaction IDs to wrap around. This
|
||||
is not a fatal problem given appropriate maintenance procedures;
|
||||
see the Administrator's Guide for details. However, it is unwise
|
||||
to depend on uniqueness of transaction IDs over the long term
|
||||
see the <citetitle>Administrator's Guide</> for details. However, it is
|
||||
unwise to depend on uniqueness of transaction IDs over the long term
|
||||
(more than one billion transactions).
|
||||
</para>
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v 1.78 2001/11/06 16:29:51 thomas Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v 1.79 2001/11/19 09:05:01 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -953,7 +953,7 @@ DecodeDateTime(char **field, int *ftype, int nf,
|
||||
if (tm->tm_year > 0)
|
||||
tm->tm_year = -(tm->tm_year - 1);
|
||||
else
|
||||
elog(ERROR, "Inconsistant use of year %04d and 'BC'", tm->tm_year);
|
||||
elog(ERROR, "Inconsistent use of year %04d and 'BC'", tm->tm_year);
|
||||
}
|
||||
else if (is2digits)
|
||||
{
|
||||
@ -1405,7 +1405,7 @@ DecodeDate(char *str, int fmask, int *tmask, struct tm * tm)
|
||||
if (tm->tm_year > 0)
|
||||
tm->tm_year = -(tm->tm_year - 1);
|
||||
else
|
||||
elog(ERROR, "Inconsistant use of year %04d and 'BC'", tm->tm_year);
|
||||
elog(ERROR, "Inconsistent use of year %04d and 'BC'", tm->tm_year);
|
||||
}
|
||||
else if (is2digits)
|
||||
{
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
/* -----------------------------------------------------------------------
|
||||
* formatting.c
|
||||
*
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v 1.44 2001/11/05 17:46:29 momjian Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v 1.45 2001/11/19 09:05:01 tgl Exp $
|
||||
*
|
||||
*
|
||||
* Portions Copyright (c) 1999-2000, PostgreSQL Global Development Group
|
||||
@ -3050,7 +3050,7 @@ to_timestamp(PG_FUNCTION_ARGS)
|
||||
if (tm.tm_year > 0)
|
||||
tm.tm_year = -(tm.tm_year - 1);
|
||||
else
|
||||
elog(ERROR, "Inconsistant use of year %04d and 'BC'", tm.tm_year);
|
||||
elog(ERROR, "Inconsistent use of year %04d and 'BC'", tm.tm_year);
|
||||
}
|
||||
|
||||
if (tmfc.j)
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/adt/varlena.c,v 1.75 2001/11/18 12:07:07 ishii Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/utils/adt/varlena.c,v 1.76 2001/11/19 09:05:02 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -328,7 +328,7 @@ textcat(PG_FUNCTION_ARGS)
|
||||
* - string length
|
||||
*
|
||||
* If the starting position is zero or less, then return from the start of the string
|
||||
* adjusting the length to be consistant with the "negative start" per SQL92.
|
||||
* adjusting the length to be consistent with the "negative start" per SQL92.
|
||||
* If the length is less than zero, return the remaining string.
|
||||
*
|
||||
* Note that the arguments operate on octet length,
|
||||
@ -740,7 +740,7 @@ byteacat(PG_FUNCTION_ARGS)
|
||||
* - string length
|
||||
*
|
||||
* If the starting position is zero or less, then return from the start of the string
|
||||
* adjusting the length to be consistant with the "negative start" per SQL92.
|
||||
* adjusting the length to be consistent with the "negative start" per SQL92.
|
||||
* If the length is less than zero, return the remaining string.
|
||||
*
|
||||
*/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user