Update description of numeric constants to match 7.3 reality.
Miscellaneous other copy-editing.
This commit is contained in:
Tom Lane
parent
2b2cf392fe
commit
c918be6a17
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.28 2002/06/11 15:32:32 thomas Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.29 2002/10/20 05:05:46 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="tutorial-advanced">
|
||||
|
|
@ -130,8 +130,8 @@ ERROR: <unnamed> referential integrity violation - key referenced from we
|
|||
<para>
|
||||
The behavior of foreign keys can be finely tuned to your
|
||||
application. We will not go beyond this simple example in this
|
||||
tutorial, but just refer you to the <citetitle>Reference
|
||||
Manual</citetitle> for more information. Making correct use of
|
||||
tutorial, but just refer you to &cite-reference;
|
||||
for more information. Making correct use of
|
||||
foreign keys will definitely improve the quality of your database
|
||||
applications, so you are strongly encouraged to learn about them.
|
||||
</para>
|
||||
|
|
@ -394,9 +394,8 @@ SELECT name, altitude
|
|||
<productname>PostgreSQL</productname> has many features not
|
||||
touched upon in this tutorial introduction, which has been
|
||||
oriented toward newer users of <acronym>SQL</acronym>. These
|
||||
features are discussed in more detail in both the
|
||||
<citetitle>User's Guide</citetitle> and the
|
||||
<citetitle>Programmer's Guide</citetitle>.
|
||||
features are discussed in more detail in both &cite-user;
|
||||
and &cite-programmer;.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.5 2002/09/21 18:32:52 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.6 2002/10/20 05:05:46 tgl Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
|
|
@ -10,7 +10,7 @@
|
|||
explaining how tables are created and modified and what features are
|
||||
available to control what data is stored in the tables.
|
||||
Subsequently, we discuss how tables can be organized into
|
||||
namespaces, and how privileges can be assigned to tables. Finally,
|
||||
schemas, and how privileges can be assigned to tables. Finally,
|
||||
we will briefly look at other features that affect the data storage,
|
||||
such as views, functions, and triggers. Detailed information on
|
||||
these topics is found in &cite-programmer;.
|
||||
|
|
@ -78,7 +78,7 @@ CREATE TABLE my_first_table (
|
|||
<literal>second_column</literal> and the type <type>integer</type>.
|
||||
The table and column names follow the identifier syntax explained
|
||||
in <xref linkend="sql-syntax-identifiers">. The type names are
|
||||
also identifiers, but there are some exceptions. Note that the
|
||||
usually also identifiers, but there are some exceptions. Note that the
|
||||
column list is comma-separated and surrounded by parentheses.
|
||||
</para>
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ CREATE TABLE products (
|
|||
<tip>
|
||||
<para>
|
||||
When you create many interrelated tables it is wise to choose a
|
||||
consistent naming patter for the tables and columns. For
|
||||
consistent naming pattern for the tables and columns. For
|
||||
instance, there is a choice of using singular or plural nouns for
|
||||
table names, both of which are favored by some theorist or other.
|
||||
</para>
|
||||
|
|
@ -287,7 +287,7 @@ CREATE TABLE products (
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The default value may be a scalar expression, which well be
|
||||
The default value may be a scalar expression, which will be
|
||||
evaluated whenever the default value is inserted
|
||||
(<emphasis>not</emphasis> when the table is created).
|
||||
</para>
|
||||
|
|
@ -618,7 +618,8 @@ CREATE TABLE example (
|
|||
|
||||
<para>
|
||||
A foreign key constraint specifies that the values in a column (or
|
||||
a group of columns) must match the values in some other column.
|
||||
a group of columns) must match the values appearing in some row
|
||||
of another table.
|
||||
We say this maintains the <firstterm>referential
|
||||
integrity</firstterm> between two related tables.
|
||||
</para>
|
||||
|
|
@ -758,7 +759,7 @@ CREATE TABLE order_items (
|
|||
<para>
|
||||
Restricting and cascading deletes are the two most common options.
|
||||
<literal>RESTRICT</literal> can also be written as <literal>NO
|
||||
ACTON</literal> and it's also the default if you don't specify
|
||||
ACTION</literal> and it's also the default if you don't specify
|
||||
anything. There are two other options for what should happen with
|
||||
the foreign key columns when a primary key is deleted:
|
||||
<literal>SET NULL</literal> and <literal>SET DEFAULT</literal>.
|
||||
|
|
@ -981,7 +982,7 @@ SET SQL_Inheritance TO OFF;
|
|||
<para>Add columns,</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Remove a column,</para>
|
||||
<para>Remove columns,</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add constraints,</para>
|
||||
|
|
@ -993,10 +994,10 @@ SET SQL_Inheritance TO OFF;
|
|||
<para>Change default values,</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Rename a column,</para>
|
||||
<para>Rename columns,</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Rename the table.</para>
|
||||
<para>Rename tables.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
@ -1270,7 +1271,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
|
|||
</itemizedlist>
|
||||
|
||||
Schemas are analogous to directories at the operating system level,
|
||||
but schemas cannot be nested.
|
||||
except that schemas cannot be nested.
|
||||
</para>
|
||||
|
||||
<sect2 id="ddl-schemas-create">
|
||||
|
|
@ -1341,7 +1342,7 @@ DROP SCHEMA myschema CASCADE;
|
|||
(since this is one of the ways to restrict the activities of your
|
||||
users to well-defined namespaces). The syntax for that is:
|
||||
<programlisting>
|
||||
CREATE SCHEMA <replaceable>schemaname</replaceable> AUTHORIZATON <replaceable>username</replaceable>;
|
||||
CREATE SCHEMA <replaceable>schemaname</replaceable> AUTHORIZATION <replaceable>username</replaceable>;
|
||||
</programlisting>
|
||||
You can even omit the schema name, in which case the schema name
|
||||
will be the same as the user name. See <xref
|
||||
|
|
@ -1359,9 +1360,9 @@ CREATE SCHEMA <replaceable>schemaname</replaceable> AUTHORIZATON <replaceable>us
|
|||
|
||||
<para>
|
||||
In the previous sections we created tables without specifying any
|
||||
schema names. Those tables (and other objects) are automatically
|
||||
put into a schema named <quote>public</quote>. Every new database
|
||||
contains such a schema. Thus, the following are equivalent:
|
||||
schema names. By default, such tables (and other objects) are
|
||||
automatically put into a schema named <quote>public</quote>. Every new
|
||||
database contains such a schema. Thus, the following are equivalent:
|
||||
<programlisting>
|
||||
CREATE TABLE products ( ... );
|
||||
</programlisting>
|
||||
|
|
@ -1550,7 +1551,7 @@ REVOKE CREATE ON public FROM PUBLIC;
|
|||
|
||||
<para>
|
||||
Schemas can be used to organize your data in many ways. There are
|
||||
a few usage patterns are recommended and are easily supported by
|
||||
a few usage patterns that are recommended and are easily supported by
|
||||
the default configuration:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -1558,7 +1559,7 @@ REVOKE CREATE ON public FROM PUBLIC;
|
|||
If you do not create any schemas then all users access the
|
||||
public schema implicitly. This simulates the situation where
|
||||
schemas are not available at all. This setup is mainly
|
||||
recommended when there is only a single user or few cooperating
|
||||
recommended when there is only a single user or a few cooperating
|
||||
users in a database. This setup also allows smooth transition
|
||||
from the non-schema-aware world.
|
||||
</para>
|
||||
|
|
@ -1586,7 +1587,7 @@ REVOKE CREATE ON public FROM PUBLIC;
|
|||
additional functions provided by third parties, etc.), put them
|
||||
into separate schemas. Remember to grant appropriate
|
||||
privileges to allow the other users to access them. Users can
|
||||
then refer to these additional object by qualifying the names
|
||||
then refer to these additional objects by qualifying the names
|
||||
with a schema name, or they can put the additional schemas into
|
||||
their path, as they choose.
|
||||
</para>
|
||||
|
|
@ -1690,9 +1691,10 @@ ERROR: Cannot drop table products because other objects depend on it
|
|||
<screen>
|
||||
DROP TABLE products CASCADE;
|
||||
</screen>
|
||||
and all the dependent objects will be removed. Actually, this
|
||||
and all the dependent objects will be removed. In this case, it
|
||||
doesn't remove the orders table, it only removes the foreign key
|
||||
constraint.
|
||||
constraint. (If you want to check what DROP ... CASCADE will do,
|
||||
run DROP without CASCADE and read the NOTICEs.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -1709,7 +1711,8 @@ DROP TABLE products CASCADE;
|
|||
According to the SQL standard, specifying either
|
||||
<literal>RESTRICT</literal> or <literal>CASCADE</literal> is
|
||||
required. No database system actually implements it that way, but
|
||||
the defaults might be different.
|
||||
whether the default behavior is <literal>RESTRICT</literal> or
|
||||
<literal>CASCADE</literal> varies across systems.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
|
|
@ -1718,7 +1721,8 @@ DROP TABLE products CASCADE;
|
|||
Foreign key constraint dependencies and serial column dependencies
|
||||
from <productname>PostgreSQL</productname> versions prior to 7.3
|
||||
are <emphasis>not</emphasis> maintained or created during the
|
||||
upgrade process. All other dependency types survive the upgrade.
|
||||
upgrade process. All other dependency types will be properly
|
||||
created during an upgrade.
|
||||
</para>
|
||||
</note>
|
||||
</sect1>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/dml.sgml,v 1.1 2002/08/05 19:44:57 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/dml.sgml,v 1.2 2002/10/20 05:05:46 tgl Exp $ -->
|
||||
|
||||
<chapter id="dml">
|
||||
<title>Data Manipulation</title>
|
||||
|
|
@ -119,8 +119,8 @@ INSERT INTO products DEFAULT VALUES;
|
|||
necessarily possible to directly specify which row to update.
|
||||
Instead, you specify which conditions a row must meet in order to
|
||||
be updated. Only if you have a primary key in the table (no matter
|
||||
whether you declared it or not) you can address rows individually
|
||||
by choosing a condition that matches the primary key only.
|
||||
whether you declared it or not) can you reliably address individual rows,
|
||||
by choosing a condition that matches the primary key.
|
||||
Graphical database access tools rely on this fact to allow you to
|
||||
update rows individually.
|
||||
</para>
|
||||
|
|
@ -195,5 +195,13 @@ UPDATE mytable SET a = 5, b = 3, c = 1 WHERE a > 0;
|
|||
DELETE FROM products WHERE price = 10;
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you simply write
|
||||
<programlisting>
|
||||
DELETE FROM products;
|
||||
</programlisting>
|
||||
then all rows in the table will be deleted! Caveat programmer.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.17 2002/09/20 18:39:41 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.18 2002/10/20 05:05:46 tgl Exp $ -->
|
||||
|
||||
<chapter id="queries">
|
||||
<title>Queries</title>
|
||||
|
|
@ -35,13 +35,12 @@ SELECT * FROM table1;
|
|||
<literal>table1</literal>. (The method of retrieval depends on the
|
||||
client application. For example, the
|
||||
<application>psql</application> program will display an ASCII-art
|
||||
table on the screen, client libraries will offer functions to
|
||||
table on the screen, while client libraries will offer functions to
|
||||
retrieve individual rows and columns.) The select list
|
||||
specification <literal>*</literal> means all columns that the table
|
||||
expression happens to provide. A select list can also select a
|
||||
subset of the available columns or even make calculations on the
|
||||
columns before retrieving them; see <xref
|
||||
linkend="queries-select-lists">. For example, if
|
||||
subset of the available columns or make calculations using the
|
||||
columns. For example, if
|
||||
<literal>table1</literal> has columns named <literal>a</>,
|
||||
<literal>b</>, and <literal>c</> (and perhaps others) you can make
|
||||
the following query:
|
||||
|
|
@ -50,6 +49,7 @@ SELECT a, b + c FROM table1;
|
|||
</programlisting>
|
||||
(assuming that <literal>b</> and <literal>c</> are of a numerical
|
||||
data type).
|
||||
See <xref linkend="queries-select-lists"> for more details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -62,7 +62,7 @@ SELECT a, b + c FROM table1;
|
|||
SELECT 3 * 4;
|
||||
</programlisting>
|
||||
This is more useful if the expressions in the select list return
|
||||
varying results. For example, you could call a function this way.
|
||||
varying results. For example, you could call a function this way:
|
||||
<programlisting>
|
||||
SELECT random();
|
||||
</programlisting>
|
||||
|
|
@ -266,7 +266,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
|||
<para>
|
||||
First, an inner join is performed. Then, for each row in
|
||||
T1 that does not satisfy the join condition with any row in
|
||||
T2, a joined row is returned with null values in columns of
|
||||
T2, a joined row is added with null values in columns of
|
||||
T2. Thus, the joined table unconditionally has at least
|
||||
one row for each row in T1.
|
||||
</para>
|
||||
|
|
@ -280,7 +280,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
|||
<para>
|
||||
First, an inner join is performed. Then, for each row in
|
||||
T2 that does not satisfy the join condition with any row in
|
||||
T1, a joined row is returned with null values in columns of
|
||||
T1, a joined row is added with null values in columns of
|
||||
T1. This is the converse of a left join: the result table
|
||||
will unconditionally have a row for each row in T2.
|
||||
</para>
|
||||
|
|
@ -294,10 +294,10 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
|||
<para>
|
||||
First, an inner join is performed. Then, for each row in
|
||||
T1 that does not satisfy the join condition with any row in
|
||||
T2, a joined row is returned with null values in columns of
|
||||
T2, a joined row is added with null values in columns of
|
||||
T2. Also, for each row of T2 that does not satisfy the
|
||||
join condition with any row in T1, a joined row with null
|
||||
values in the columns of T1 is returned.
|
||||
values in the columns of T1 is added.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -602,7 +602,7 @@ FROM a NATURAL JOIN b WHERE b.val > 5
|
|||
<literal>JOIN</> syntax in the <literal>FROM</> clause is
|
||||
probably not as portable to other SQL database products. For
|
||||
outer joins there is no choice in any case: they must be done in
|
||||
the <literal>FROM</> clause. A <literal>ON</>/<literal>USING</>
|
||||
the <literal>FROM</> clause. An <literal>ON</>/<literal>USING</>
|
||||
clause of an outer join is <emphasis>not</> equivalent to a
|
||||
<literal>WHERE</> condition, because it determines the addition
|
||||
of rows (for unmatched input rows) as well as the removal of rows
|
||||
|
|
@ -692,11 +692,11 @@ SELECT <replaceable>select_list</replaceable>
|
|||
|
||||
<para>
|
||||
In the second query, we could not have written <literal>SELECT *
|
||||
FROM test1 GROUP BY x;</literal>, because there is no single value
|
||||
FROM test1 GROUP BY x</literal>, because there is no single value
|
||||
for the column <literal>y</> that could be associated with each
|
||||
group. In general, if a table is grouped, columns that are not
|
||||
used in the grouping cannot be referenced except in aggregate
|
||||
expressions, for example:
|
||||
expressions. An example with aggregate expressions is:
|
||||
<screen>
|
||||
<prompt>=></> <userinput>SELECT x, sum(y) FROM test1 GROUP BY x;</>
|
||||
x | sum
|
||||
|
|
@ -717,25 +717,25 @@ SELECT <replaceable>select_list</replaceable>
|
|||
they have a known constant value per group.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<tip>
|
||||
<para>
|
||||
Grouping without aggregate expressions effectively calculates the
|
||||
set of distinct values in a column. This can also be achieved
|
||||
using the <literal>DISTINCT</> clause (see <xref
|
||||
linkend="queries-distinct">).
|
||||
</para>
|
||||
</note>
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
Here is another example: A <function>sum(sales)</function> on a
|
||||
Here is another example: <function>sum(sales)</function> on a
|
||||
table grouped by product code gives the total sales for each
|
||||
product, not the total sales on all products.
|
||||
<programlisting>
|
||||
SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
|
||||
FROM products p LEFT JOIN sales s USING (product_id)
|
||||
GROUP BY pid, p.name, p.price;
|
||||
GROUP BY product_id, p.name, p.price;
|
||||
</programlisting>
|
||||
In this example, the columns <literal>pid</literal>,
|
||||
In this example, the columns <literal>product_id</literal>,
|
||||
<literal>p.name</literal>, and <literal>p.price</literal> must be
|
||||
in the <literal>GROUP BY</> clause since they are referenced in
|
||||
the query select list. (Depending on how exactly the products
|
||||
|
|
@ -767,7 +767,7 @@ SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
|
|||
SELECT <replaceable>select_list</replaceable> FROM ... <optional>WHERE ...</optional> GROUP BY ... HAVING <replaceable>boolean_expression</replaceable>
|
||||
</synopsis>
|
||||
Expressions in the <literal>HAVING</> clause can refer both to
|
||||
grouped expressions and to ungrouped expression (which necessarily
|
||||
grouped expressions and to ungrouped expressions (which necessarily
|
||||
involve an aggregate function).
|
||||
</para>
|
||||
|
||||
|
|
@ -794,7 +794,7 @@ SELECT <replaceable>select_list</replaceable> FROM ... <optional>WHERE ...</opti
|
|||
Again, a more realistic example:
|
||||
<programlisting>
|
||||
SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit
|
||||
FROM products p LEFT JOIN sales s USING (pid)
|
||||
FROM products p LEFT JOIN sales s USING (product_id)
|
||||
WHERE s.date > CURRENT_DATE - INTERVAL '4 weeks'
|
||||
GROUP BY product_id, p.name, p.price, p.cost
|
||||
HAVING sum(p.price * s.units) > 5000;
|
||||
|
|
@ -1093,7 +1093,7 @@ SELECT a AS b FROM table1 ORDER BY a;
|
|||
<para>
|
||||
If more than one sort column is specified, the later entries are
|
||||
used to sort rows that are equal under the order imposed by the
|
||||
earlier sort specifications.
|
||||
earlier sort columns.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.25 2002/01/20 22:19:56 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.26 2002/10/20 05:05:46 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="tutorial-sql">
|
||||
|
|
@ -205,7 +205,7 @@ INSERT INTO weather VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');
|
|||
Constants that are not simple numeric values usually must be
|
||||
surrounded by single quotes (<literal>'</>), as in the example.
|
||||
The
|
||||
<type>date</type> column is actually quite flexible in what it
|
||||
<type>date</type> type is actually quite flexible in what it
|
||||
accepts, but for this tutorial we will stick to the unambiguous
|
||||
format shown here.
|
||||
</para>
|
||||
|
|
@ -259,8 +259,7 @@ COPY weather FROM '/home/user/weather.txt';
|
|||
where the file name for the source file must be available to the
|
||||
backend server machine, not the client, since the backend server
|
||||
reads the file directly. You can read more about the
|
||||
<command>COPY</command> command in the <citetitle>Reference
|
||||
Manual</citetitle>.
|
||||
<command>COPY</command> command in &cite-reference;.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -341,10 +340,7 @@ SELECT * FROM weather
|
|||
<indexterm><primary>duplicate</primary></indexterm>
|
||||
|
||||
As a final note, you can request that the results of a select can
|
||||
be returned in sorted order or with duplicate rows removed. (Just
|
||||
to make sure the following won't confuse you,
|
||||
<literal>DISTINCT</literal> and <literal>ORDER BY</literal> can be
|
||||
used separately.)
|
||||
be returned in sorted order or with duplicate rows removed:
|
||||
|
||||
<programlisting>
|
||||
SELECT DISTINCT city
|
||||
|
|
@ -359,6 +355,9 @@ SELECT DISTINCT city
|
|||
San Francisco
|
||||
(2 rows)
|
||||
</screen>
|
||||
|
||||
<literal>DISTINCT</literal> and <literal>ORDER BY</literal> can be
|
||||
used separately, of course.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.24 2002/08/13 20:40:43 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.25 2002/10/20 05:05:46 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="tutorial-start">
|
||||
|
|
@ -31,8 +31,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.24 2002/08/13 20:40:43 momji
|
|||
|
||||
<para>
|
||||
If you are installing <productname>PostgreSQL</productname>
|
||||
yourself, then refer to the <citetitle>Administrator's
|
||||
Guide</citetitle> for instructions on installation, and return to
|
||||
yourself, then refer to &cite-admin;
|
||||
for instructions on installation, and return to
|
||||
this guide when the installation is complete. Be sure to follow
|
||||
closely the section about setting up the appropriate environment
|
||||
variables.
|
||||
|
|
@ -87,7 +87,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.24 2002/08/13 20:40:43 momji
|
|||
<para>
|
||||
The user's client (frontend) application that wants to perform
|
||||
database operations. Client applications can be very diverse
|
||||
in nature: They could be a text-oriented tool, a graphical
|
||||
in nature: a client could be a text-oriented tool, a graphical
|
||||
application, a web server that accesses the database to
|
||||
display web pages, or a specialized database maintenance tool.
|
||||
Some client applications are supplied with the
|
||||
|
|
@ -292,8 +292,7 @@ createdb: database creation failed
|
|||
<para>
|
||||
Writing a custom application, using one of the several
|
||||
available language bindings. These possibilities are discussed
|
||||
further in <citetitle>The PostgreSQL Programmer's
|
||||
Guide</citetitle>.
|
||||
further in &cite-programmer;.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
|
@ -353,13 +352,13 @@ mydb=#
|
|||
<prompt>mydb=></prompt> <userinput>SELECT version();</userinput>
|
||||
version
|
||||
----------------------------------------------------------------
|
||||
PostgreSQL 7.2devel on i586-pc-linux-gnu, compiled by GCC 2.96
|
||||
PostgreSQL 7.3devel on i586-pc-linux-gnu, compiled by GCC 2.96
|
||||
(1 row)
|
||||
|
||||
<prompt>mydb=></prompt> <userinput>SELECT current_date;</userinput>
|
||||
date
|
||||
------------
|
||||
2001-08-31
|
||||
2002-08-31
|
||||
(1 row)
|
||||
|
||||
<prompt>mydb=></prompt> <userinput>SELECT 2 + 2;</userinput>
|
||||
|
|
@ -391,8 +390,8 @@ mydb=#
|
|||
and <command>psql</command> will quit and return you to your
|
||||
command shell. (For more internal commands, type
|
||||
<literal>\?</literal> at the <command>psql</command> prompt.) The
|
||||
full capabilities of <command>psql</command> are documented in the
|
||||
<citetitle>Reference Manual</citetitle>. If <productname>PostgreSQL</> is
|
||||
full capabilities of <command>psql</command> are documented in
|
||||
&cite-reference;. If <productname>PostgreSQL</> is
|
||||
installed correctly you can also type <literal>man psql</literal>
|
||||
at the operating system shell prompt to see the documentation. In
|
||||
this tutorial we will not use these features explicitly, but you
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.70 2002/09/21 18:32:54 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.71 2002/10/20 05:05:46 tgl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
|
|
@ -73,8 +73,8 @@ INSERT INTO MY_TABLE VALUES (3, 'hi there');
|
|||
a <token>SET</token> token to appear in a certain position, and
|
||||
this particular variation of <command>INSERT</command> also
|
||||
requires a <token>VALUES</token> in order to be complete. The
|
||||
precise syntax rules for each command are described in the
|
||||
<citetitle>Reference Manual</citetitle>.
|
||||
precise syntax rules for each command are described in
|
||||
&cite-reference;.
|
||||
</para>
|
||||
|
||||
<sect2 id="sql-syntax-identifiers">
|
||||
|
|
@ -206,9 +206,9 @@ UPDATE "my_table" SET "a" = 5;
|
|||
</indexterm>
|
||||
|
||||
<para>
|
||||
There are four kinds of <firstterm>implicitly-typed
|
||||
There are three kinds of <firstterm>implicitly-typed
|
||||
constants</firstterm> in <productname>PostgreSQL</productname>:
|
||||
strings, bit strings, integers, and floating-point numbers.
|
||||
strings, bit strings, and numbers.
|
||||
Constants can also be specified with explicit types, which can
|
||||
enable more accurate representation and more efficient handling by
|
||||
the system. The implicit constants are described below; explicit
|
||||
|
|
@ -271,8 +271,9 @@ SELECT 'foobar';
|
|||
<programlisting>
|
||||
SELECT 'foo' 'bar';
|
||||
</programlisting>
|
||||
is not valid syntax, and <productname>PostgreSQL</productname> is
|
||||
consistent with <acronym>SQL9x</acronym> in this regard.
|
||||
is not valid syntax. (This slightly bizarre behavior is specified
|
||||
by <acronym>SQL9x</acronym>; <productname>PostgreSQL</productname> is
|
||||
following the standard.)
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
|
|
@ -290,52 +291,52 @@ SELECT 'foo' 'bar';
|
|||
opening quote (no intervening whitespace), e.g.,
|
||||
<literal>B'1001'</literal>. The only characters allowed within
|
||||
bit-string constants are <literal>0</literal> and
|
||||
<literal>1</literal>. Bit-string constants can be continued
|
||||
<literal>1</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Alternatively, bit-string constants can be specified in hexadecimal
|
||||
notation, using a leading <literal>X</literal> (upper or lower case),
|
||||
e.g., <literal>X'1FF'</literal>. This notation is equivalent to
|
||||
a bit-string constant with four binary digits for each hex digit.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Both forms of bit-string constant can be continued
|
||||
across lines in the same way as regular string constants.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Integer Constants</title>
|
||||
|
||||
<para>
|
||||
Integer constants in SQL are sequences of decimal digits (0
|
||||
though 9) with no decimal point and no exponent. The range of legal values
|
||||
depends on which integer data type is used, but the plain
|
||||
<type>integer</type> type accepts values ranging from -2147483648
|
||||
to +2147483647. (The optional plus or minus sign is actually a
|
||||
separate unary operator and not part of the integer constant.)
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Floating-Point Constants</title>
|
||||
<title>Numeric Constants</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>floating point</primary>
|
||||
<primary>numeric</primary>
|
||||
<secondary>constants</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
Floating-point constants are accepted in these general forms:
|
||||
Numeric constants are accepted in these general forms:
|
||||
<synopsis>
|
||||
<replaceable>digits</replaceable>
|
||||
<replaceable>digits</replaceable>.<optional><replaceable>digits</replaceable></optional><optional>e<optional>+-</optional><replaceable>digits</replaceable></optional>
|
||||
<optional><replaceable>digits</replaceable></optional>.<replaceable>digits</replaceable><optional>e<optional>+-</optional><replaceable>digits</replaceable></optional>
|
||||
<replaceable>digits</replaceable>e<optional>+-</optional><replaceable>digits</replaceable>
|
||||
</synopsis>
|
||||
where <replaceable>digits</replaceable> is one or more decimal
|
||||
digits. At least one digit must be before or after the decimal
|
||||
point. At least one digit must follow the exponent delimiter
|
||||
(<literal>e</literal>) if that field is present.
|
||||
Thus, a floating-point constant is distinguished from an integer
|
||||
constant by the presence of either the decimal point or the
|
||||
exponent clause (or both). There must not be a space or other
|
||||
characters embedded in the constant.
|
||||
digits (0 through 9). At least one digit must be before or after the
|
||||
decimal point, if one is used. At least one digit must follow the
|
||||
exponent marker (<literal>e</literal>), if one is present.
|
||||
There may not be any spaces or other characters embedded in the
|
||||
constant. Notice that any leading plus or minus sign is not actually
|
||||
considered part of the constant; it is an operator applied to the
|
||||
constant.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These are some examples of valid floating-point constants:
|
||||
These are some examples of valid numeric constants:
|
||||
<literallayout>
|
||||
42
|
||||
3.5
|
||||
4.
|
||||
.001
|
||||
|
|
@ -345,14 +346,29 @@ SELECT 'foo' 'bar';
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Floating-point constants are of type <type>DOUBLE
|
||||
PRECISION</type>. <type>REAL</type> can be specified explicitly
|
||||
by using <acronym>SQL</acronym> string notation or
|
||||
<productname>PostgreSQL</productname> type notation:
|
||||
A numeric constant that contains neither a decimal point nor an
|
||||
exponent is initially presumed to be type <type>integer</> if its
|
||||
value fits in type <type>integer</> (32 bits); otherwise it is
|
||||
presumed to be type <type>bigint</> if its
|
||||
value fits in type <type>bigint</> (64 bits); otherwise it is
|
||||
taken to be type <type>numeric</>. Constants that contain decimal
|
||||
points and/or exponents are always initially presumed to be type
|
||||
<type>numeric</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The initially assigned data type of a numeric constant is just a
|
||||
starting point for the type resolution algorithms. In most
|
||||
cases the constant will be automatically coerced to the most
|
||||
appropriate type depending on context. When necessary, you
|
||||
can force a numeric value to be interpreted as a specific
|
||||
data type by casting it. For example, you can force a numeric
|
||||
value to be treated as type <type>real</> (<type>float4</>)
|
||||
by writing
|
||||
|
||||
<programlisting>
|
||||
REAL '1.23' -- string style
|
||||
'1.23'::REAL -- PostgreSQL (historical) style
|
||||
1.23::REAL -- PostgreSQL (historical) style
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect3>
|
||||
|
|
@ -921,7 +937,7 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
|
|||
table (possibly qualified), or an alias for a table defined by means of a
|
||||
FROM clause, or
|
||||
the key words <literal>NEW</literal> or <literal>OLD</literal>.
|
||||
(NEW and OLD can only appear in the action portion of a rule,
|
||||
(NEW and OLD can only appear in rules,
|
||||
while other correlation names can be used in any SQL statement.)
|
||||
The correlation name and separating dot may be omitted if the column name
|
||||
is unique
|
||||
|
|
@ -939,8 +955,9 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
|
|||
|
||||
<para>
|
||||
A positional parameter reference is used to indicate a parameter
|
||||
in an SQL function. Typically this is used in SQL function
|
||||
definition statements. The form of a parameter is:
|
||||
that is supplied externally to an SQL statement. Parameters are
|
||||
used in SQL function definitions and in prepared queries.
|
||||
The form of a parameter reference is:
|
||||
<synopsis>
|
||||
$<replaceable>number</replaceable>
|
||||
</synopsis>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.15 2001/09/02 23:27:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.16 2002/10/20 05:05:46 tgl Exp $
|
||||
-->
|
||||
|
||||
<book id="tutorial">
|
||||
|
|
@ -25,13 +25,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.15 2001/09/02 23:27
|
|||
</para>
|
||||
|
||||
<para>
|
||||
After you have worked through this tutorial you might want to move on
|
||||
to reading the <![%single-book;[<citetitle>User's
|
||||
Guide</citetitle>]]><![%set-of-books;[<xref linkend="user">]]> to
|
||||
gain a more formal knowledge of the SQL language, or the
|
||||
<![%single-book;[<citetitle>Programmer's
|
||||
Guide</citetitle>]]><![%set-of-books;[<xref linkend="programmer">]]>
|
||||
for information about developing applications for
|
||||
After you have worked through this tutorial you might want to move on to
|
||||
reading &cite-user; to gain a more formal knowledge of the SQL language,
|
||||
or &cite-programmer; for information about developing applications for
|
||||
<productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue