mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-30 19:00:29 +08:00
Minor copy-editing.
This commit is contained in:
parent
b72c1b9f63
commit
0684043e39
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.16 2003/08/10 01:20:34 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.17 2003/08/14 23:13:27 tgl Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -490,7 +490,7 @@ CREATE TABLE products (
|
||||
price numeric NOT NULL CHECK (price > 0)
|
||||
);
|
||||
</programlisting>
|
||||
The order doesn't matter. It does not necessarily affect in which
|
||||
The order doesn't matter. It does not necessarily determine in which
|
||||
order the constraints are checked.
|
||||
</para>
|
||||
|
||||
@ -578,7 +578,7 @@ CREATE TABLE products (
|
||||
least) two rows in the table where the values of each of the
|
||||
corresponding columns that are part of the constraint are equal.
|
||||
However, null values are not considered equal in this
|
||||
consideration. That means, in the presence of a multicolumn
|
||||
consideration. That means even in the presence of a
|
||||
unique constraint it is possible to store an unlimited number of
|
||||
rows that contain a null value in at least one of the constrained
|
||||
columns. This behavior conforms to the SQL standard, but we have
|
||||
@ -629,7 +629,7 @@ CREATE TABLE example (
|
||||
A primary key indicates that a column or group of columns can be
|
||||
used as a unique identifier for rows in the table. (This is a
|
||||
direct consequence of the definition of a primary key. Note that
|
||||
a unique constraint does not, in fact, provide a unique identifier
|
||||
a unique constraint does not, by itself, provide a unique identifier
|
||||
because it does not exclude null values.) This is useful both for
|
||||
documentation purposes and for client applications. For example,
|
||||
a GUI application that allows modifying row values probably needs
|
||||
@ -850,8 +850,9 @@ CREATE TABLE capitals (
|
||||
In this case, a row of capitals <firstterm>inherits</firstterm> all
|
||||
attributes (name, population, and altitude) from its
|
||||
parent, cities. The type of the attribute name is
|
||||
<type>text</type>, a native <productname>PostgreSQL</productname> type for variable length
|
||||
ASCII strings. The type of the attribute population is
|
||||
<type>text</type>, a native <productname>PostgreSQL</productname> type
|
||||
for variable length character strings. The type of the attribute
|
||||
population is
|
||||
<type>float</type>, a native <productname>PostgreSQL</productname> type for double precision
|
||||
floating-point numbers. State capitals have an extra
|
||||
attribute, state, that shows their state. In <productname>PostgreSQL</productname>,
|
||||
@ -964,7 +965,7 @@ WHERE c.altitude > 500 and c.tableoid = p.oid;
|
||||
<para>
|
||||
In previous versions of <productname>PostgreSQL</productname>, the
|
||||
default was not to get access to child tables. This was found to
|
||||
be error prone and is also in violation of the SQL standard. Under the old
|
||||
be error prone and is also in violation of the SQL99 standard. Under the old
|
||||
syntax, to get the sub-tables you append <literal>*</literal> to the table name.
|
||||
For example
|
||||
<programlisting>
|
||||
@ -1180,7 +1181,8 @@ ALTER TABLE products RENAME TO items;
|
||||
<note>
|
||||
<para>
|
||||
To change the owner of a table, index, sequence, or view, use the
|
||||
<command>ALTER TABLE</command> command.
|
||||
<xref linkend="sql-altertable" endterm="sql-altertable-title">
|
||||
command.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
@ -1192,7 +1194,8 @@ ALTER TABLE products RENAME TO items;
|
||||
<literal>USAGE</>, and <literal>ALL PRIVILEGES</>. For complete
|
||||
information on the different types of privileges supported by
|
||||
<productname>PostgreSQL</productname>, refer to the
|
||||
<command>GRANT</command> reference page. The following sections
|
||||
<xref linkend="sql-grant" endterm="sql-grant-title">
|
||||
reference page. The following sections
|
||||
and chapters will also show you how those privileges are used.
|
||||
</para>
|
||||
|
||||
@ -1453,8 +1456,8 @@ SHOW search_path;
|
||||
$user,public
|
||||
</screen>
|
||||
The first element specifies that a schema with the same name as
|
||||
the current user is to be searched. Since no such schema exists
|
||||
yet, this entry is ignored. The second element refers to the
|
||||
the current user is to be searched. If no such schema exists,
|
||||
the entry is ignored. The second element refers to the
|
||||
public schema that we have seen already.
|
||||
</para>
|
||||
|
||||
@ -1737,7 +1740,7 @@ DROP TABLE products CASCADE;
|
||||
the possible dependencies varies with the type of the object. You
|
||||
can also write <literal>RESTRICT</literal> instead of
|
||||
<literal>CASCADE</literal> to get the default behavior which is to
|
||||
restrict drops of objects that other objects depend on.
|
||||
prevent drops of objects that other objects depend on.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.21 2003/04/10 01:22:44 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.22 2003/08/14 23:13:27 tgl Exp $ -->
|
||||
|
||||
<chapter id="queries">
|
||||
<title>Queries</title>
|
||||
@ -1208,10 +1208,10 @@ SELECT <replaceable>select_list</replaceable>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When using <literal>LIMIT</>, it is a good idea to use an
|
||||
When using <literal>LIMIT</>, it is important to use an
|
||||
<literal>ORDER BY</> clause that constrains the result rows into a
|
||||
unique order. Otherwise you will get an unpredictable subset of
|
||||
the query's rows. --- You may be asking for the tenth through
|
||||
the query's rows. You may be asking for the tenth through
|
||||
twentieth rows, but tenth through twentieth in what ordering? The
|
||||
ordering is unknown, unless you specified <literal>ORDER BY</>.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.81 2003/08/09 22:50:22 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.82 2003/08/14 23:13:27 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -450,14 +450,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
'{{1,2,3},{4,5,6},{7,8,9}}'
|
||||
</programlisting>
|
||||
This constant is a two-dimensional, 3-by-3 array consisting of three
|
||||
subarrays of integers.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Individual array elements can be placed between double-quote
|
||||
marks (<literal>"</literal>) <!-- " --> to avoid ambiguity
|
||||
problems with respect to whitespace. Without quote marks, the
|
||||
array-value parser will skip leading whitespace.
|
||||
subarrays of integers. For more information see <xref linkend="arrays">.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1190,8 +1183,10 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
||||
one of the two standard cast syntaxes is used to do a run-time
|
||||
conversion, it will internally invoke a registered function to
|
||||
perform the conversion. By convention, these conversion functions
|
||||
have the same name as their output type, but this is not something
|
||||
that a portable application should rely on.)
|
||||
have the same name as their output type, and thus the <quote>function-like
|
||||
syntax</> is nothing more than a direct invocation of the underlying
|
||||
conversion function. Obviously, this is not something that a portable
|
||||
application should rely on.)
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -1349,8 +1344,10 @@ SELECT ... WHERE x <> 0 AND y/x > 1.5;
|
||||
<programlisting>
|
||||
SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 1.5 ELSE false END;
|
||||
</programlisting>
|
||||
A <literal>CASE</> construct used in this fashion will defeat optimization attempts,
|
||||
so it should only be done when necessary.
|
||||
A <literal>CASE</> construct used in this fashion will defeat optimization
|
||||
attempts, so it should only be done when necessary. (In this particular
|
||||
example, it would doubtless be best to sidestep the problem by writing
|
||||
<literal>y > 1.5*x</> instead.)
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.31 2003/05/26 00:11:27 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.32 2003/08/14 23:13:27 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter Id="typeconv">
|
||||
@ -113,15 +113,16 @@ with, and perhaps converted to, the types of the target columns.
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>UNION</literal> and <literal>CASE</literal> constructs
|
||||
<literal>UNION</literal>, <literal>CASE</literal>, and <literal>ARRAY</literal> constructs
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Since all query results from a unionized <literal>SELECT</literal> statement must appear in a single
|
||||
set of columns, the types of the results
|
||||
of each <literal>SELECT</> clause must be matched up and converted to a uniform set.
|
||||
Similarly, the branch expressions of a <literal>CASE</> construct must be converted to
|
||||
a common type so that the <literal>CASE</> expression as a whole has a known output type.
|
||||
Since all query results from a unionized <literal>SELECT</literal> statement
|
||||
must appear in a single set of columns, the types of the results of each
|
||||
<literal>SELECT</> clause must be matched up and converted to a uniform set.
|
||||
Similarly, the branch expressions of a <literal>CASE</> construct must be
|
||||
converted to a common type so that the <literal>CASE</> expression as a whole
|
||||
has a known output type. The same holds for <literal>ARRAY</> constructs.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -754,7 +755,8 @@ padding spaces.
|
||||
</sect1>
|
||||
|
||||
<sect1 id="typeconv-union-case">
|
||||
<title><literal>UNION</> and <literal>CASE</> Constructs</title>
|
||||
<title><literal>UNION</literal>, <literal>CASE</literal>, and
|
||||
<literal>ARRAY</literal> Constructs</title>
|
||||
|
||||
<para>
|
||||
SQL <literal>UNION</> constructs must match up possibly dissimilar types to
|
||||
@ -762,12 +764,13 @@ become a single result set. The resolution algorithm is applied separately
|
||||
to each output column of a union query. The <literal>INTERSECT</> and
|
||||
<literal>EXCEPT</> constructs resolve dissimilar types in the same way as
|
||||
<literal>UNION</>.
|
||||
A <literal>CASE</> construct also uses the identical algorithm to match up its
|
||||
component expressions and select a result data type.
|
||||
A <literal>CASE</> construct uses the identical algorithm to match up its
|
||||
component expressions and select a result data type, as does <literal>ARRAY</>.
|
||||
</para>
|
||||
|
||||
<procedure>
|
||||
<title><literal>UNION</> and <literal>CASE</> Type Resolution</title>
|
||||
<title><literal>UNION</literal>, <literal>CASE</literal>, and
|
||||
<literal>ARRAY</literal> Type Resolution</title>
|
||||
|
||||
<step performance="required">
|
||||
<para>
|
||||
|
Loading…
Reference in New Issue
Block a user