mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-11-27 07:21:09 +08:00
New blood and fresh air for tutorial
This commit is contained in:
parent
5608f13028
commit
60ce9e9279
@ -1,32 +1,203 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.21 2001/01/13 23:58:55 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.22 2001/09/02 23:27:49 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="advanced">
|
<chapter id="tutorial-advanced">
|
||||||
<title>Advanced <productname>Postgres</productname> <acronym>SQL</acronym> Features</title>
|
<title>Advanced Features</title>
|
||||||
|
|
||||||
|
<sect1 id="tutorial-advanced-intro">
|
||||||
|
<title>Introduction</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Having covered the basics of using
|
In the previous chapter we have covered the basics of using
|
||||||
<productname>Postgres</productname> <acronym>SQL</acronym> to
|
<acronym>SQL</acronym> to store and access your data in a
|
||||||
access your data, we will now discuss those features of
|
<productname>PostgreSQL</productname>. We will now discuss some
|
||||||
<productname>Postgres</productname> that distinguish it from conventional data
|
more advanced features of <acronym>SQL</acronym> that simplify the
|
||||||
managers. These features include inheritance, time
|
management and prevent loss or corruption of your data. Finally,
|
||||||
travel and non-atomic data values (array- and
|
we will look at some <productname>PostgreSQL</productname>
|
||||||
set-valued attributes).
|
extensions.
|
||||||
Examples in this section can also be found in
|
|
||||||
<filename>advance.sql</filename> in the tutorial directory.
|
|
||||||
(Refer to <xref linkend="QUERY"> for how to use it.)
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1 id="inheritance">
|
<para>
|
||||||
<title>Inheritance</title>
|
This chapter will on occasion refer to examples found in <xref
|
||||||
|
linkend="tutorial-sql"> to change or improve them, so it will be
|
||||||
|
of advantage if you have read that chapter. Some examples from
|
||||||
|
this chapter can also be found in
|
||||||
|
<filename>advanced.sql</filename> in the tutorial directory. This
|
||||||
|
file also contains some example data to load, which is not
|
||||||
|
repeated here. (Refer to <xref linkend="tutorial-sql-intro"> for
|
||||||
|
how to use the file.)
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
|
<sect1 id="tutorial-views">
|
||||||
|
<title>Views</title>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-views">
|
||||||
|
<primary>view</primary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Let's create two tables. The capitals table contains
|
Refer back to the queries in <xref linkend="tutorial-join">.
|
||||||
state capitals that are also cities. Naturally, the
|
Suppose the combined listing of weather records and city location
|
||||||
capitals table should inherit from cities.
|
is of particular interest to your application, but you don't want
|
||||||
|
to type the query each time you need it. You can create a
|
||||||
|
<firstterm>view</firstterm> over the query, which gives a name to
|
||||||
|
the query that you can refer to like an ordinary table.
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
CREATE VIEW myview AS
|
||||||
|
SELECT city, temp_lo, temp_hi, prcp, date, location
|
||||||
|
FROM weather, cities
|
||||||
|
WHERE city = name;
|
||||||
|
|
||||||
|
SELECT * FROM myview;
|
||||||
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Making liberal use of views is a key aspect of good SQL database
|
||||||
|
design. Views allow you to encapsulate the details of the
|
||||||
|
structure of your tables, which may change as your application
|
||||||
|
evolves, behind consistent interfaces.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Views can be used in almost any place a real table can be used.
|
||||||
|
Building views upon other views is not uncommon.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
|
<sect1 id="tutorial-fk">
|
||||||
|
<title>Foreign Keys</title>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-fk">
|
||||||
|
<primary>foreign key</primary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-fk">
|
||||||
|
<primary>referential integrity</primary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Recall the <classname>weather</classname> and the
|
||||||
|
<classname>cities</classname> tables from <xref
|
||||||
|
linkend="tutorial-sql">. Consider the following problem: You
|
||||||
|
want to make sure that no one can insert rows in the
|
||||||
|
<classname>weather</classname> table that do not have a matching
|
||||||
|
entry in the <classname>cities</classname> table. This is called
|
||||||
|
maintaining the <firstterm>referential integrity</firstterm> of
|
||||||
|
your data. In simplistic database systems this would be
|
||||||
|
implemented (if at all) by first looking at the
|
||||||
|
<classname>cities</classname> table to check if a matching record
|
||||||
|
exists, and then inserting or rejecting the new
|
||||||
|
<classname>weather</classname> records. This approach has a
|
||||||
|
number of problems and is very inconvenient, so
|
||||||
|
<productname>PostgreSQL</productname> can do this for you.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The new declaration of the tables would look like this:
|
||||||
|
|
||||||
|
<programlisting>
|
||||||
|
CREATE TABLE cities (
|
||||||
|
name varchar(80) primary key,
|
||||||
|
location point
|
||||||
|
);
|
||||||
|
|
||||||
|
CREATE TABLE weather (
|
||||||
|
city varchar(80) references weather,
|
||||||
|
temp_lo int,
|
||||||
|
temp_hi int,
|
||||||
|
prcp real,
|
||||||
|
date date
|
||||||
|
);
|
||||||
|
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
|
Now try inserting an invalid record:
|
||||||
|
|
||||||
|
<programlisting>
|
||||||
|
INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
|
<screen>
|
||||||
|
ERROR: <unnamed> referential integrity violation - key referenced from weather not found in cities
|
||||||
|
</screen>
|
||||||
|
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The behavior of foreign keys can be finely tuned to your
|
||||||
|
application. We will not go beyond this simple example in this
|
||||||
|
tutorial and refer you to the <citetitle>Reference
|
||||||
|
Manual</citetitle> 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>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
|
<sect1 id="tutorial-transactions">
|
||||||
|
<title>Transactions</title>
|
||||||
|
|
||||||
|
<comment>This section needs to be written.</comment>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
|
<sect1 id="tutorial-inheritance">
|
||||||
|
<title>Inheritance</title>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-inheritance">
|
||||||
|
<primary>inheritance</primary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Inheritance is a concept from object-oriented databases. It opens
|
||||||
|
up interesting new possibilities of database design.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Let's create two tables: A table <classname>cities</classname>
|
||||||
|
and a table <classname>capitals</classname>. Naturally, capitals
|
||||||
|
are also cities, so you want some way to show the capitals
|
||||||
|
implicitly when you list all cities. If you're really clever you
|
||||||
|
might invent some scheme like this:
|
||||||
|
|
||||||
|
<programlisting>
|
||||||
|
CREATE TABLE capitals (
|
||||||
|
name text,
|
||||||
|
population real,
|
||||||
|
altitude int, -- (in ft)
|
||||||
|
state char(2)
|
||||||
|
);
|
||||||
|
|
||||||
|
CREATE TABLE non_capitals (
|
||||||
|
name text,
|
||||||
|
population real,
|
||||||
|
altitude int -- (in ft)
|
||||||
|
);
|
||||||
|
|
||||||
|
CREATE VIEW cities AS
|
||||||
|
SELECT name, population, altitude FROM capitals
|
||||||
|
UNION
|
||||||
|
SELECT name, population, altitude FROM non_capitals;
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
|
This works OK as far as querying goes, but it gets ugly when you
|
||||||
|
need to update several rows, to name one thing.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
A better solution is this:
|
||||||
|
|
||||||
|
<programlisting>
|
||||||
CREATE TABLE cities (
|
CREATE TABLE cities (
|
||||||
name text,
|
name text,
|
||||||
population real,
|
population real,
|
||||||
@ -36,245 +207,93 @@ CREATE TABLE cities (
|
|||||||
CREATE TABLE capitals (
|
CREATE TABLE capitals (
|
||||||
state char(2)
|
state char(2)
|
||||||
) INHERITS (cities);
|
) INHERITS (cities);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
In this case, a row of capitals <firstterm>inherits</firstterm> all
|
In this case, a row of <classname>capitals</classname>
|
||||||
columns (name, population, and altitude) from its
|
<firstterm>inherits</firstterm> all columns (<structfield>name</>,
|
||||||
parent, cities. The type of the column name is
|
<structfield>population</>, and <structfield>altitude</>) from its
|
||||||
|
<firstterm>parent</firstterm>, <classname>cities</classname>. The
|
||||||
|
type of the column <structfield>name</structfield> is
|
||||||
<type>text</type>, a native <productname>Postgres</productname>
|
<type>text</type>, a native <productname>Postgres</productname>
|
||||||
type for variable length
|
type for variable length character strings. State capitals have
|
||||||
ASCII strings. The type of the column population is
|
an extra column, state, that shows their state. In
|
||||||
<type>real</type>, a type for single precision
|
<productname>PostgreSQL</productname>, a table can inherit from
|
||||||
floating point numbers. State capitals have an extra
|
zero or more other tables.
|
||||||
column, state, that shows their state.
|
|
||||||
In <productname>Postgres</productname>,
|
|
||||||
a table can inherit from zero or more other tables,
|
|
||||||
and a query can reference either all rows of a
|
|
||||||
table or all rows of a tables plus all of its
|
|
||||||
descendants.
|
|
||||||
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
The inheritance hierarchy is a directed acyclic graph.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For example, the following query finds the names of all cities,
|
For example, the following query finds the names of all cities,
|
||||||
including state capitals, that are located at an altitude
|
including state capitals, that are located at an altitude
|
||||||
over 500ft:
|
over 500 ft.:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT name, altitude
|
SELECT name, altitude
|
||||||
FROM cities
|
FROM cities
|
||||||
WHERE altitude > 500;
|
WHERE altitude > 500;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
which returns:
|
which returns:
|
||||||
|
|
||||||
<programlisting>
|
<screen>
|
||||||
+----------+----------+
|
name | altitude
|
||||||
|name | altitude |
|
-----------+----------
|
||||||
+----------+----------+
|
Las Vegas | 2174
|
||||||
|Las Vegas | 2174 |
|
Mariposa | 1953
|
||||||
+----------+----------+
|
Madison | 845
|
||||||
|Mariposa | 1953 |
|
(3 rows)
|
||||||
+----------+----------+
|
</screen>
|
||||||
|Madison | 845 |
|
|
||||||
+----------+----------+
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
On the other hand, the following query finds
|
On the other hand, the following query finds
|
||||||
all the cities that are not state capitals and
|
all the cities that are not state capitals and
|
||||||
are situated at an altitude of 500ft or higher:
|
are situated at an altitude of 500 ft. or higher:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT name, altitude
|
SELECT name, altitude
|
||||||
FROM ONLY cities
|
FROM ONLY cities
|
||||||
WHERE altitude > 500;
|
WHERE altitude > 500;
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
+----------+----------+
|
<screen>
|
||||||
|name | altitude |
|
name | altitude
|
||||||
+----------+----------+
|
-----------+----------
|
||||||
|Las Vegas | 2174 |
|
Las Vegas | 2174
|
||||||
+----------+----------+
|
Mariposa | 1953
|
||||||
|Mariposa | 1953 |
|
(2 rows)
|
||||||
+----------+----------+
|
</screen>
|
||||||
</programlisting>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Here the <quote>ONLY</quote> before cities indicates that the query should
|
Here the <literal>ONLY</literal> before <literal>cities</literal>
|
||||||
be run over only the cities table, and not tables below cities in the
|
indicates that the query should be run over only the
|
||||||
inheritance hierarchy. Many of the commands that we
|
<classname>cities</classname> table, and not tables below
|
||||||
have already discussed -- <command>SELECT</command>,
|
<classname>cities</classname> in the inheritance hierarchy. Many
|
||||||
<command>UPDATE</command> and <command>DELETE</command> --
|
of the commands that we have already discussed --
|
||||||
support this <quote>ONLY</quote> notation.
|
<command>SELECT</command>, <command>UPDATE</command> and
|
||||||
|
<command>DELETE</command> -- support this <literal>ONLY</literal>
|
||||||
|
notation.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
|
||||||
<title>Deprecated</title>
|
|
||||||
<para>
|
|
||||||
In previous versions of <productname>Postgres</productname>, the
|
|
||||||
default was not to get access to child tables. This was found to
|
|
||||||
be error prone and is also in violation of SQL99. Under the old
|
|
||||||
syntax, to get the sub-tables you append "*" to the table name.
|
|
||||||
For example
|
|
||||||
<programlisting>
|
|
||||||
SELECT * from cities*;
|
|
||||||
</programlisting>
|
|
||||||
You can still explicitly specify scanning child tables by appending
|
|
||||||
"*", as well as explicitly specify not scanning child tables by
|
|
||||||
writing <quote>ONLY</quote>. But beginning in version 7.1, the default
|
|
||||||
behavior for an undecorated table name is to scan its child tables
|
|
||||||
too, whereas before the default was not to do so. To get the old
|
|
||||||
default behavior, set the configuration option
|
|
||||||
<literal>SQL_Inheritance</literal> to off, e.g.,
|
|
||||||
<programlisting>
|
|
||||||
SET SQL_Inheritance TO OFF;
|
|
||||||
</programlisting>
|
|
||||||
or add a line in your <filename>postgresql.conf</filename> file.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="non-atomic-values">
|
|
||||||
<title>Non-Atomic Values</title>
|
<sect1 id="tutorial-conclusion">
|
||||||
|
<title>Conclusion</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
One of the tenets of the relational model is that the
|
<productname>PostgreSQL</productname> has many features not
|
||||||
columns of a table are atomic.
|
touched upon in this tutorial introduction, which has been
|
||||||
<productname>Postgres</productname> does not
|
oriented toward newer users of <acronym>SQL</acronym>. These
|
||||||
have this restriction; columns can themselves contain
|
features are discussed in more detail in both the
|
||||||
sub-values that can be accessed from the query
|
<citetitle>User's Guide</citetitle> and the
|
||||||
language. For example, you can create columns that
|
<citetitle>Programmer's Guide</citetitle>.
|
||||||
are arrays of base types.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>Arrays</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
<productname>Postgres</productname> allows columns of a
|
|
||||||
row to be defined
|
|
||||||
as fixed-length or variable-length multi-dimensional
|
|
||||||
arrays. Arrays of any base type or user-defined type
|
|
||||||
can be created. To illustrate their use, we first create a
|
|
||||||
table with arrays of base types.
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
CREATE TABLE SAL_EMP (
|
|
||||||
name text,
|
|
||||||
pay_by_quarter integer[],
|
|
||||||
schedule text[][]
|
|
||||||
);
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The above query will create a table named SAL_EMP with
|
If you feel you need more introductory material, please visit the
|
||||||
a <firstterm>text</firstterm> string (name), a one-dimensional
|
<ulink url="http://www.postgresql.org">PostgreSQL web
|
||||||
array of <firstterm>integer</firstterm>
|
site</ulink> for links to more resources.
|
||||||
(pay_by_quarter), which represents the employee's
|
|
||||||
salary by quarter and a two-dimensional array of
|
|
||||||
<firstterm>text</firstterm>
|
|
||||||
(schedule), which represents the employee's weekly
|
|
||||||
schedule. Now we do some <firstterm>INSERT</firstterm>s;
|
|
||||||
note that when
|
|
||||||
appending to an array, we enclose the values within
|
|
||||||
braces and separate them by commas. If you know
|
|
||||||
<firstterm>C</firstterm>,
|
|
||||||
this is not unlike the syntax for initializing structures.
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
INSERT INTO SAL_EMP
|
|
||||||
VALUES ('Bill',
|
|
||||||
'{10000, 10000, 10000, 10000}',
|
|
||||||
'{{"meeting", "lunch"}, {}}');
|
|
||||||
|
|
||||||
INSERT INTO SAL_EMP
|
|
||||||
VALUES ('Carol',
|
|
||||||
'{20000, 25000, 25000, 25000}',
|
|
||||||
'{{"talk", "consult"}, {"meeting"}}');
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
By default, <productname>Postgres</productname> uses the
|
|
||||||
"one-based" numbering
|
|
||||||
convention for arrays -- that is, an array of n elements
|
|
||||||
starts with array[1] and ends with array[n].
|
|
||||||
Now, we can run some queries on SAL_EMP. First, we
|
|
||||||
show how to access a single element of an array at a
|
|
||||||
time. This query retrieves the names of the employees
|
|
||||||
whose pay changed in the second quarter:
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
SELECT name
|
|
||||||
FROM SAL_EMP
|
|
||||||
WHERE SAL_EMP.pay_by_quarter[1] <>
|
|
||||||
SAL_EMP.pay_by_quarter[2];
|
|
||||||
|
|
||||||
+------+
|
|
||||||
|name |
|
|
||||||
+------+
|
|
||||||
|Carol |
|
|
||||||
+------+
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
This query retrieves the third quarter pay of all
|
|
||||||
employees:
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
SELECT SAL_EMP.pay_by_quarter[3] FROM SAL_EMP;
|
|
||||||
|
|
||||||
|
|
||||||
+---------------+
|
|
||||||
|pay_by_quarter |
|
|
||||||
+---------------+
|
|
||||||
|10000 |
|
|
||||||
+---------------+
|
|
||||||
|25000 |
|
|
||||||
+---------------+
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
We can also access arbitrary slices of an array (subarrays)
|
|
||||||
by specifying both lower and upper bounds for
|
|
||||||
each subscript. This query retrieves the first item on
|
|
||||||
Bill's schedule for the first two days of the week.
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
SELECT SAL_EMP.schedule[1:2][1:1]
|
|
||||||
FROM SAL_EMP
|
|
||||||
WHERE SAL_EMP.name = 'Bill';
|
|
||||||
|
|
||||||
+-------------------+
|
|
||||||
|schedule |
|
|
||||||
+-------------------+
|
|
||||||
|{{"meeting"},{""}} |
|
|
||||||
+-------------------+
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
|
||||||
</sect2>
|
|
||||||
</sect1>
|
|
||||||
|
|
||||||
<sect1 id="more-advanced">
|
|
||||||
<title>More Advanced Features</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
<productname>Postgres</productname> has many features not touched
|
|
||||||
upon in this
|
|
||||||
tutorial introduction, which has been oriented toward newer users of
|
|
||||||
<acronym>SQL</acronym>.
|
|
||||||
These are discussed in more detail in both the User's and
|
|
||||||
Programmer's Guides.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -1,88 +0,0 @@
|
|||||||
<Chapter Id="arch">
|
|
||||||
<TITLE>Architecture</TITLE>
|
|
||||||
|
|
||||||
<Sect1 id="arch-concepts">
|
|
||||||
<Title><ProductName>Postgres</ProductName> Architectural Concepts</Title>
|
|
||||||
|
|
||||||
<Para>
|
|
||||||
Before we begin, you should understand the basic
|
|
||||||
<ProductName>Postgres</ProductName> system architecture. Understanding how the
|
|
||||||
parts of <ProductName>Postgres</ProductName> interact will make the next chapter
|
|
||||||
somewhat clearer.
|
|
||||||
In database jargon, <ProductName>Postgres</ProductName> uses a simple "process
|
|
||||||
per-user" client/server model. A <ProductName>Postgres</ProductName> session
|
|
||||||
consists of the following cooperating Unix processes (programs):
|
|
||||||
</Para>
|
|
||||||
|
|
||||||
<ItemizedList>
|
|
||||||
<ListItem>
|
|
||||||
<Para>
|
|
||||||
A supervisory daemon process (<Application>postmaster</Application>),
|
|
||||||
</Para>
|
|
||||||
</ListItem>
|
|
||||||
<ListItem>
|
|
||||||
<Para>
|
|
||||||
the user's frontend application (e.g., the <Application>psql</Application> program), and
|
|
||||||
</Para>
|
|
||||||
</ListItem>
|
|
||||||
<ListItem>
|
|
||||||
<Para>
|
|
||||||
the one or more backend database servers (the <Application>postgres</Application> process itself).
|
|
||||||
</Para>
|
|
||||||
</ListItem>
|
|
||||||
</ItemizedList>
|
|
||||||
|
|
||||||
<Para>
|
|
||||||
A single <Application>postmaster</Application> manages a given collection of
|
|
||||||
databases on a single host. Such a collection of
|
|
||||||
databases is called a cluster (of databases). Frontend
|
|
||||||
applications that wish to access a given database
|
|
||||||
within a cluster make calls to the library.
|
|
||||||
The library sends user requests over the network to the
|
|
||||||
<Application>postmaster</Application> (<XRef LinkEnd="ARCH-CLIENTSERVER">),
|
|
||||||
which in turn starts a new backend server process
|
|
||||||
|
|
||||||
<Figure Id="ARCH-CLIENTSERVER">
|
|
||||||
<Title>How a connection is established</Title>
|
|
||||||
<Graphic Align="center" FileRef="clientserver.gif" Format="GIF"></Graphic>
|
|
||||||
</Figure>
|
|
||||||
|
|
||||||
and connects the
|
|
||||||
frontend process to the new server. From
|
|
||||||
that point on, the frontend process and the backend
|
|
||||||
server communicate without intervention by the
|
|
||||||
<Application>postmaster</Application>. Hence, the <Application>postmaster</Application> is always running, waiting
|
|
||||||
for requests, whereas frontend and backend processes
|
|
||||||
come and go.
|
|
||||||
</Para>
|
|
||||||
|
|
||||||
<Para>
|
|
||||||
The <FileName>libpq</FileName> library allows a single
|
|
||||||
frontend to make multiple connections to backend processes.
|
|
||||||
However, the frontend application is still a
|
|
||||||
single-threaded process. Multithreaded frontend/backend
|
|
||||||
connections are not currently supported in <FileName>libpq</FileName>.
|
|
||||||
One implication of this architecture is that the
|
|
||||||
<Application>postmaster</Application> and the backend always run on the same
|
|
||||||
machine (the database server), while the frontend
|
|
||||||
application may run anywhere. You should keep this
|
|
||||||
in mind,
|
|
||||||
because the files that can be accessed on a client
|
|
||||||
machine may not be accessible (or may only be accessed
|
|
||||||
using a different filename) on the database server
|
|
||||||
machine.
|
|
||||||
</Para>
|
|
||||||
|
|
||||||
<Para>
|
|
||||||
You should also be aware that the <Application>postmaster</Application> and
|
|
||||||
postgres servers run with the user-id of the <ProductName>Postgres</ProductName>
|
|
||||||
"superuser." Note that the <ProductName>Postgres</ProductName> superuser does not
|
|
||||||
have to be a special user (e.g., a user named
|
|
||||||
"postgres"). Furthermore, the <ProductName>Postgres</ProductName> superuser
|
|
||||||
should
|
|
||||||
definitely not be the Unix superuser ("root")! In any
|
|
||||||
case, all files relating to a database should belong to
|
|
||||||
this <ProductName>Postgres</ProductName> superuser.
|
|
||||||
</Para>
|
|
||||||
</sect1>
|
|
||||||
</Chapter>
|
|
@ -1,7 +1,8 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.14 2001/08/26 21:17:12 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.15 2001/09/02 23:27:49 petere Exp $ -->
|
||||||
|
|
||||||
<!entity history SYSTEM "history.sgml">
|
<!entity history SYSTEM "history.sgml">
|
||||||
<!entity info SYSTEM "info.sgml">
|
<!entity info SYSTEM "info.sgml">
|
||||||
|
<!entity intro SYSTEM "intro.sgml">
|
||||||
<!entity legal SYSTEM "legal.sgml">
|
<!entity legal SYSTEM "legal.sgml">
|
||||||
<!entity notation SYSTEM "notation.sgml">
|
<!entity notation SYSTEM "notation.sgml">
|
||||||
<!entity problems SYSTEM "problems.sgml">
|
<!entity problems SYSTEM "problems.sgml">
|
||||||
@ -12,12 +13,12 @@
|
|||||||
|
|
||||||
<!-- tutorial -->
|
<!-- tutorial -->
|
||||||
<!entity advanced SYSTEM "advanced.sgml">
|
<!entity advanced SYSTEM "advanced.sgml">
|
||||||
<!entity arch SYSTEM "arch.sgml">
|
|
||||||
<!entity intro SYSTEM "intro.sgml">
|
|
||||||
<!entity query SYSTEM "query.sgml">
|
<!entity query SYSTEM "query.sgml">
|
||||||
<!entity sql SYSTEM "sql.sgml">
|
|
||||||
<!entity start SYSTEM "start.sgml">
|
<!entity start SYSTEM "start.sgml">
|
||||||
|
|
||||||
|
<!-- currently unused, but contains some interesting information -->
|
||||||
|
<!entity sql SYSTEM "sql.sgml">
|
||||||
|
|
||||||
<!-- user's guide -->
|
<!-- user's guide -->
|
||||||
<!entity array SYSTEM "array.sgml">
|
<!entity array SYSTEM "array.sgml">
|
||||||
<!entity datatype SYSTEM "datatype.sgml">
|
<!entity datatype SYSTEM "datatype.sgml">
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/info.sgml,v 1.11 2001/02/03 19:03:26 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/info.sgml,v 1.12 2001/09/02 23:27:49 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<sect1 id="resources">
|
<sect1 id="resources">
|
||||||
@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/info.sgml,v 1.11 2001/02/03 19:03:26 petere
|
|||||||
<term>Tutorial</term>
|
<term>Tutorial</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
An introduction for new users. Does not cover advanced features.
|
An informal introduction for new users
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -1,414 +1,405 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.16 2001/07/15 13:45:03 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.17 2001/09/02 23:27:49 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="start">
|
<chapter id="tutorial-start">
|
||||||
<title>Getting Started</title>
|
<title>Getting Started</title>
|
||||||
|
|
||||||
<abstract>
|
<sect1 id="tutorial-install">
|
||||||
<para>
|
<title>Installation</title>
|
||||||
How to begin work with <productname>Postgres</productname> for a new user.
|
|
||||||
</para>
|
|
||||||
</abstract>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Some of the steps required to use <productname>Postgres</productname>
|
Before you can use <productname>PostgreSQL</productname> you need
|
||||||
can be performed by any Postgres user, and some must be done by
|
to install it, of course. It is possible that
|
||||||
the site database administrator. This site administrator
|
<productname>PostgreSQL</productname> is already installed at your
|
||||||
is the person who installed the software, created
|
site, either because it was included in your operating system
|
||||||
the database directories and started the
|
distribution or because the system administrator already installed
|
||||||
<application>postmaster</application>
|
it. If that is the case, you should obtain information from the
|
||||||
process. This person does not have to be the Unix
|
operating system documentation or your system administrator about
|
||||||
superuser ("root")
|
how to access <productname>PostgreSQL</productname>.
|
||||||
or the computer system administrator; a person can install and use
|
|
||||||
<productname>Postgres</productname> without any special accounts or
|
|
||||||
privileges.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you are installing <productname>Postgres</productname> yourself, then
|
If you are not sure whether <productname>PostgreSQL</productname>
|
||||||
refer to the Administrator's Guide for instructions on
|
is already available or whether you can use it for your
|
||||||
installation, and return
|
experimentation then you can install it yourself. Doing so is not
|
||||||
to this guide when the installation is complete.
|
hard and it can be a good exercise.
|
||||||
|
<productname>PostgreSQL</productname> can be installed by any
|
||||||
|
unprivileged user, no superuser (<systemitem>root</systemitem>)
|
||||||
|
access is required.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Throughout this manual, any examples that begin with
|
If you are installing <productname>PostgreSQL</productname>
|
||||||
the character "<literal>%</literal>" are commands that should be typed
|
yourself, then refer to the <citetitle>Administrator's
|
||||||
at the Unix shell prompt. Examples that begin with the
|
Guide</citetitle> for instructions on installation, and return to
|
||||||
character "<literal>*</literal>" are commands in the Postgres query
|
this guide when the installation is complete. Be sure to follow
|
||||||
language, Postgres <acronym>SQL</acronym>.
|
closely the section about setting up the appropriate environment
|
||||||
</para>
|
variables.
|
||||||
|
|
||||||
<sect1 id="start-env">
|
|
||||||
<title>Setting Up Your Environment</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
This section discusses how to set up
|
|
||||||
your own environment so that you can use frontend
|
|
||||||
applications. We assume <productname>Postgres</productname> has
|
|
||||||
already been
|
|
||||||
successfully installed and started; refer to the Administrator's Guide
|
|
||||||
and the installation notes
|
|
||||||
for how to install Postgres.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>Postgres</productname> is a client/server
|
If your site administrator has not set things up in the default
|
||||||
application. As a user,
|
way, you may have some more work to do. For example, if the
|
||||||
you only need access to the client portions of the installation
|
database server machine is a remote machine, you will need to set
|
||||||
(an example
|
the <envar>PGHOST</envar> environment variable to the name of the
|
||||||
of a client application is the interactive monitor
|
database server machine. The environment variable
|
||||||
<application>psql</application>).
|
<envar>PGPORT</envar> may also have to be set. The bottom line is
|
||||||
For simplicity,
|
this: if you try to start an application program and it complains
|
||||||
we will assume that <productname>Postgres</productname> has been
|
that it cannot connect to the database, you should consult your
|
||||||
installed in the
|
site administrator or, if that is you, the documentation to make
|
||||||
directory <filename>/usr/local/pgsql</filename>. Therefore, wherever
|
sure that your environment is properly set up. If you did not
|
||||||
you see the directory <filename>/usr/local/pgsql</filename> you should
|
understand the preceding paragraph then read the next section.
|
||||||
substitute the name of the directory where
|
|
||||||
<productname>Postgres</productname> is
|
|
||||||
actually installed.
|
|
||||||
All <productname>Postgres</productname> commands are installed in
|
|
||||||
the directory
|
|
||||||
<filename>/usr/local/pgsql/bin</filename>. Therefore, you should add
|
|
||||||
this directory to your shell command path. If you use
|
|
||||||
a variant of the Berkeley C shell, such as csh or tcsh,
|
|
||||||
you would add
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
% set path = ( /usr/local/pgsql/bin path )
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
in the <filename>.login</filename> file in your home directory.
|
|
||||||
If you use
|
|
||||||
a variant of the Bourne shell, such as sh, ksh, or
|
|
||||||
bash, then you would add
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
% PATH=/usr/local/pgsql/bin:$PATH
|
|
||||||
% export PATH
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
to the .profile file in your home directory.
|
|
||||||
From now on, we will assume that you have added the
|
|
||||||
<productname>Postgres</productname> bin directory to your path.
|
|
||||||
In addition, we
|
|
||||||
will make frequent reference to <quote>setting a shell
|
|
||||||
variable</quote> or <quote>setting an environment
|
|
||||||
variable</quote> throughout
|
|
||||||
this document. If you did not fully understand the
|
|
||||||
last paragraph on modifying your search path, you
|
|
||||||
should consult the Unix manual pages that describe your
|
|
||||||
shell before going any further.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
If your site administrator has not set things up in the
|
|
||||||
default way, you may have some more work to do. For example, if
|
|
||||||
the database
|
|
||||||
server machine is a remote machine, you
|
|
||||||
will need to set the <acronym>PGHOST</acronym> environment
|
|
||||||
variable to the name
|
|
||||||
of the database server machine. The environment variable
|
|
||||||
<acronym>PGPORT</acronym> may also have to be set.
|
|
||||||
The bottom line is this: if
|
|
||||||
you try to start an application program and it complains
|
|
||||||
that it cannot connect to the <application>postmaster</application>,
|
|
||||||
you should immediately consult your site administrator to make
|
|
||||||
sure that your
|
|
||||||
environment is properly set up.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="start-psql">
|
|
||||||
<title>Starting the Interactive Monitor (psql)</title>
|
<sect1 id="tutorial-arch">
|
||||||
|
<title>Architectural Fundamentals</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Assuming that your site administrator has properly
|
Before we proceed, you should understand the basic
|
||||||
started the <application>postmaster</application> process and
|
<productname>PostgreSQL</productname> system architecture.
|
||||||
authorized you to
|
Understanding how the parts of
|
||||||
use the database, you (as a user) may begin to start up
|
<productname>PostgreSQL</productname> interact will make the next
|
||||||
applications. As previously mentioned, you should add
|
chapter somewhat clearer.
|
||||||
<filename>/usr/local/pgsql/bin</filename> to your shell search path.
|
|
||||||
In most cases, this is all you should have to do in
|
|
||||||
terms of preparation.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Two different styles of connections
|
In database jargon, <productname>PostgreSQL</productname> uses a
|
||||||
are supported. The site administrator will have chosen to allow
|
client/server model. A <productname>PostgreSQL</productname>
|
||||||
TCP/IP network connections
|
session consists of the following cooperating processes
|
||||||
or will have restricted database access to local (same-machine)
|
(programs):
|
||||||
socket connections only.
|
|
||||||
These choices become significant if you encounter problems in
|
|
||||||
connecting to a database, since you will want to confirm that you
|
|
||||||
are choosing an allowed connection option.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<itemizedlist>
|
||||||
If you get the following error message from a
|
|
||||||
<productname>Postgres</productname>
|
|
||||||
command (such as <application>psql</application> or
|
|
||||||
<application>createdb</application>):
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
% psql template1
|
|
||||||
psql: could not connect to server: Connection refused
|
|
||||||
Is the server running locally and accepting
|
|
||||||
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
or
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
% psql -h localhost template1
|
|
||||||
psql: could not connect to server: Connection refused
|
|
||||||
Is the server running on host localhost and accepting
|
|
||||||
TCP/IP connections on port 5432?
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
it is usually because
|
|
||||||
|
|
||||||
<itemizedlist mark="bullet" spacing="compact">
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
the <application>postmaster</application> is not running,
|
A server process, which manages the database files, accepts
|
||||||
or
|
connections to the database from client applications, and
|
||||||
|
performs actions on the database on behalf of the clients. The
|
||||||
|
database server program is called
|
||||||
|
<filename>postmaster</filename>.
|
||||||
|
<indexterm><primary>postmaster</primary></indexterm>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
you are attempting to connect to the wrong server host.
|
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
|
||||||
|
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
|
||||||
|
<productname>PostgreSQL</productname> distribution, most are
|
||||||
|
developed by users.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you get the following error message:
|
As is typical of client/server applications, the client and the
|
||||||
|
server can be on different hosts. In that case they communicate
|
||||||
|
over a TCP/IP network connection. You should keep this in mind,
|
||||||
|
because the files that can be accessed on a client machine might
|
||||||
|
not be accessible (or might only be accessed using a different
|
||||||
|
file name) on the database server machine.
|
||||||
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<para>
|
||||||
FATAL 1:Feb 17 23:19:55:process userid (2360) != database owner (268)
|
The <productname>PostgreSQL</productname> server can handle
|
||||||
</programlisting>
|
multiple concurrent connections from clients. For that purpose it
|
||||||
|
starts (<quote>forks</quote>) a new process for each connection.
|
||||||
it means that the site administrator started the
|
From that point on, the client and the new server process
|
||||||
<application>postmaster</application>
|
communicate without intervention by the original
|
||||||
as the wrong user. Tell him to restart it as
|
<filename>postmaster</filename> process. Thus, the
|
||||||
the <productname>Postgres</productname> superuser.
|
<filename>postmaster</filename> is always running, waiting for
|
||||||
|
client connections, whereas client and associated server processes
|
||||||
|
come and go. (All of this is of course invisible to the user. We
|
||||||
|
only mention it here for completeness.)
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="start-manage-db">
|
|
||||||
<title>Managing a Database</title>
|
|
||||||
|
|
||||||
<para>
|
<sect1 id="tutorial-createdb">
|
||||||
Now that <productname>Postgres</productname> is up and running we
|
|
||||||
can create some
|
|
||||||
databases to experiment with. Here, we describe the
|
|
||||||
basic commands for managing a database.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Most <productname>Postgres</productname>
|
|
||||||
applications assume that the database name, if not specified, is
|
|
||||||
the same as the name on your computer
|
|
||||||
account.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If your database administrator has set up your account without
|
|
||||||
database creation privileges,
|
|
||||||
then she should have told you what the name of your database is. If
|
|
||||||
this is the case, then you
|
|
||||||
can skip the sections on creating and destroying databases.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>Creating a Database</title>
|
<title>Creating a Database</title>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-createdb">
|
||||||
|
<primary>database</primary>
|
||||||
|
<secondary>creating</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-createdb">
|
||||||
|
<primary>createdb</primary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Let's say you want to create a database named
|
The first test to see whether you can access the database server
|
||||||
<database>mydb</database>.
|
is to try to create a database. A running
|
||||||
You can do this with the following command:
|
<productname>PostgreSQL</productname> server can manage many
|
||||||
<programlisting>
|
databases. Typically, a separate database is used for each
|
||||||
% createdb mydb
|
project or for each user.
|
||||||
</programlisting>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Possibly, your site administrator has already created a database
|
||||||
|
for your use. He should have told you what the name of your
|
||||||
|
database is. In this case you can omit this step and skip ahead
|
||||||
|
to the next section.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
To create a new database, in this example named
|
||||||
|
<quote>mydb</quote>, you use the following command:
|
||||||
|
<screen>
|
||||||
|
<prompt>$</prompt> <userinput>createdb mydb</userinput>
|
||||||
|
</screen>
|
||||||
|
This should produce as response:
|
||||||
|
<screen>
|
||||||
|
CREATE DATABASE
|
||||||
|
</screen>
|
||||||
|
Is so, this step was successful and you can skip over the
|
||||||
|
remainder of this section.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you see a message similar to
|
||||||
|
<screen>
|
||||||
|
createdb: command not found
|
||||||
|
</screen>
|
||||||
|
then PostgreSQL was not installed properly. Either it was not
|
||||||
|
installed at all or the search path was not set correctly. Try
|
||||||
|
calling the command with an absolute path instead:
|
||||||
|
<screen>
|
||||||
|
<prompt>$</prompt> <userinput>/usr/local/pgsql/bin/createdb</userinput>
|
||||||
|
</screen>
|
||||||
|
The path at your site might be different. Contact your site
|
||||||
|
administrator or check back in the installation instructions to
|
||||||
|
correct the situation.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Another response could be this:
|
||||||
|
<screen>
|
||||||
|
psql: could not connect to server: Connection refused
|
||||||
|
Is the server running locally and accepting
|
||||||
|
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
|
||||||
|
createdb: database creation failed
|
||||||
|
</screen>
|
||||||
|
This means that the server was not started, or it was not started
|
||||||
|
where <command>createdb</command> expected it. Again, check the
|
||||||
|
installation instructions or consult the administrator.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you do not have the privileges required to create a database,
|
If you do not have the privileges required to create a database,
|
||||||
you will see
|
you will see the following:
|
||||||
the following:
|
<screen>
|
||||||
<programlisting>
|
ERROR: CREATE DATABASE: permission denied
|
||||||
% createdb mydb
|
createdb: database creation failed
|
||||||
NOTICE:user "your username" is not allowed to create/destroy databases
|
</screen>
|
||||||
createdb: database creation failed on mydb.
|
Not every user has authorization to create new databases. If
|
||||||
</programlisting>
|
<productname>PostgreSQL</productname> refuses to create databases
|
||||||
|
for you then the site administrator needs to grant you permission
|
||||||
|
to create databases. Consult your site administrator if this
|
||||||
|
occurs. If you installed <productname>PostgreSQL</productname>
|
||||||
|
yourself then you should log in for the purposes of this tutorial
|
||||||
|
under the user account that you started the server as.
|
||||||
|
|
||||||
|
<footnote>
|
||||||
|
<para>
|
||||||
|
As an explanation for why this works:
|
||||||
|
<productname>PostgreSQL</productname> user names are separate
|
||||||
|
from operating system user accounts. If you connect to a
|
||||||
|
database, you can choose what
|
||||||
|
<productname>PostgreSQL</productname> user name to connect as;
|
||||||
|
if you don't, it will default to the same name as your current
|
||||||
|
operating system account. As it happens, there will always be a
|
||||||
|
<productname>PostgreSQL</productname> user account that has the
|
||||||
|
same name as the operating system user that started the server,
|
||||||
|
and it also happens that that user always has permission to
|
||||||
|
create databases. Instead of logging in as that user you can
|
||||||
|
also specify the <option>-U</option> option everywhere to select
|
||||||
|
a <productname>PostgreSQL</productname> user name to connect as.
|
||||||
|
</para>
|
||||||
|
</footnote>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>Postgres</productname> allows you to create any
|
You can also create databases with other names.
|
||||||
number of databases
|
<productname>PostgreSQL</productname> allows you to create any
|
||||||
at a given site and you automatically become the
|
number of databases at a given site. Database names must have an
|
||||||
database administrator of the database you just created.
|
alphabetic first character and are limited to 32 characters in
|
||||||
Database names must have an alphabetic first
|
length. A convenient choice is to create a database with the same
|
||||||
character and are limited to 32 characters in length.
|
name as your current user name. Many tools assume that database
|
||||||
Not every user has authorization to become a database
|
name as the default, so it can save you some typing. To create
|
||||||
administrator. If <productname>Postgres</productname> refuses to
|
that database, simply type
|
||||||
create databases
|
<screen>
|
||||||
for you, then the site administrator needs to grant you
|
<prompt>$</prompt> <userinput>createdb</userinput>
|
||||||
permission to create databases. Consult your site
|
</screen>
|
||||||
administrator if this occurs.
|
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
|
||||||
|
|
||||||
<sect2>
|
<para>
|
||||||
|
If you don't want to use your database anymore you can remove it.
|
||||||
|
For example, if you are the owner (creator) of the database
|
||||||
|
<quote>mydb</quote>, you can destroy it using the following
|
||||||
|
command:
|
||||||
|
<screen>
|
||||||
|
<prompt>$</prompt> <userinput>dropdb mydb</userinput>
|
||||||
|
</screen>
|
||||||
|
(In this case, the database name does not default to the user
|
||||||
|
account name. You always need to specify it.) This action
|
||||||
|
physically removes all files associated with the database and
|
||||||
|
cannot be undone, so this should only be done with a great deal of
|
||||||
|
forethought.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
|
<sect1 id="tutorial-accessdb">
|
||||||
<title>Accessing a Database</title>
|
<title>Accessing a Database</title>
|
||||||
|
|
||||||
|
<indexterm zone="tutorial-accessdb">
|
||||||
|
<primary>psql</primary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Once you have constructed a database, you can access it
|
Once you have created a database, you can access it by:
|
||||||
by:
|
|
||||||
|
|
||||||
<itemizedlist spacing="compact" mark="bullet">
|
<itemizedlist spacing="compact" mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Running the <productname>Postgres</productname> terminal
|
Running the <productname>PostgreSQL</productname> interactive
|
||||||
monitor programs
|
terminal program, called <quote>psql</quote>, which allows you
|
||||||
(e.g. <application>psql</application>) which allows you to
|
to interactively enter, edit, and execute
|
||||||
interactively
|
<acronym>SQL</acronym> commands.
|
||||||
enter, edit, and execute <acronym>SQL</acronym> commands.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Using an existing native frontend tool like
|
Using an existing graphical frontend tool like
|
||||||
<application>pgaccess</application> or
|
<application>PgAccess</application> or
|
||||||
<application>ApplixWare</application> (via
|
<application>ApplixWare</application> (via
|
||||||
<acronym>ODBC</acronym>) to create and manipulate a
|
<acronym>ODBC</acronym>) to create and manipulate a database.
|
||||||
database.
|
These possibilities are not covered in this tutorial.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Using a language like perl or tcl which has a supported
|
Writing a custom application, using one of the several
|
||||||
interface for <productname>Postgres</productname>. Some of
|
available language bindings. These possibilities are discussed
|
||||||
these languages also have convenient and powerful GUI toolkits
|
further in <citetitle>The PostgreSQL Programmer's
|
||||||
which can help you construct custom
|
Guide</citetitle>.
|
||||||
applications. <application>pgaccess</application>, mentioned
|
|
||||||
above, is one such application written in tk/tcl and can be
|
|
||||||
used as an example.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Writing a <acronym>C</acronym> program using
|
|
||||||
the LIBPQ subroutine
|
|
||||||
library. This allows you to submit
|
|
||||||
<acronym>SQL</acronym> commands
|
|
||||||
from <acronym>C</acronym> and get answers and
|
|
||||||
status messages back to
|
|
||||||
your program. This interface is discussed further
|
|
||||||
in <citetitle>The PostgreSQL Programmer's Guide</citetitle>.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
You might want to start up <application>psql</application>,
|
You probably want to start up <command>psql</command>, to try out
|
||||||
to try out the examples in this manual.
|
the examples in this tutorial. It can be activated for the
|
||||||
It can be activated for the <database>mydb</database>
|
<quote>mydb</quote> database by typing the command:
|
||||||
database by typing the command:
|
<screen>
|
||||||
<programlisting>
|
<prompt>$</prompt> <userinput>psql mydb</userinput>
|
||||||
% psql mydb
|
</screen>
|
||||||
</programlisting>
|
If you leave off the database name then it will default to your
|
||||||
|
user account name. You already discovered this scheme in the
|
||||||
You will be greeted with the following message:
|
previous section.
|
||||||
<programlisting>
|
|
||||||
Welcome to the POSTGRESQL interactive sql monitor:
|
|
||||||
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
|
|
||||||
|
|
||||||
type \? for help on slash commands
|
|
||||||
type \q to quit
|
|
||||||
type \g or terminate with semicolon to execute query
|
|
||||||
You are currently connected to the database: template1
|
|
||||||
|
|
||||||
mydb=>
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This prompt indicates that the terminal monitor is listening
|
In <command>psql</command>, you will be greeted with the following
|
||||||
|
message:
|
||||||
|
<screen>
|
||||||
|
Welcome to psql, the PostgreSQL interactive terminal.
|
||||||
|
|
||||||
|
Type: \copyright for distribution terms
|
||||||
|
\h for help with SQL commands
|
||||||
|
\? for help on internal slash commands
|
||||||
|
\g or terminate with semicolon to execute query
|
||||||
|
\q to quit
|
||||||
|
|
||||||
|
mydb=>
|
||||||
|
</screen>
|
||||||
|
<indexterm><primary>superuser</primary></indexterm>
|
||||||
|
The last line could also be
|
||||||
|
<screen>
|
||||||
|
mydb=#
|
||||||
|
</screen>
|
||||||
|
That would mean you are a database superuser, which is most likely
|
||||||
|
the case if you installed <productname>PostgreSQL</productname>
|
||||||
|
yourself. Being a superuser means that you are not subject to
|
||||||
|
access controls. For the purpose of this tutorial this is not of
|
||||||
|
importance.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you have encountered problems starting <command>psql</command>
|
||||||
|
then go back to the previous section. The diagnostics of
|
||||||
|
<command>psql</command> and <command>createdb</command> are
|
||||||
|
similar, and if the latter worked the former should work as well.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The last line printed out by <command>psql</command> is the
|
||||||
|
prompt, and it indicates that <command>psql</command> is listening
|
||||||
to you and that you can type <acronym>SQL</acronym> queries into a
|
to you and that you can type <acronym>SQL</acronym> queries into a
|
||||||
workspace maintained by the terminal monitor.
|
workspace maintained by <command>psql</command>. Try out these
|
||||||
The <application>psql</application> program responds to escape
|
commands:
|
||||||
codes that begin
|
<indexterm><primary>version</primary></indexterm>
|
||||||
with the backslash character, "<literal>\</literal>" For example, you
|
<screen>
|
||||||
can get help on the syntax of various
|
<prompt>mydb=></prompt> <userinput>SELECT version();</userinput>
|
||||||
<productname>Postgres</productname> <acronym>SQL</acronym>
|
version
|
||||||
|
----------------------------------------------------------------
|
||||||
|
PostgreSQL 7.2devel on i586-pc-linux-gnu, compiled by GCC 2.96
|
||||||
|
(1 row)
|
||||||
|
|
||||||
|
<prompt>mydb=></prompt> <userinput>SELECT current_date;</userinput>
|
||||||
|
date
|
||||||
|
------------
|
||||||
|
2001-08-31
|
||||||
|
(1 row)
|
||||||
|
|
||||||
|
<prompt>mydb=></prompt> <userinput>SELECT 2 + 2;</userinput>
|
||||||
|
?column?
|
||||||
|
----------
|
||||||
|
4
|
||||||
|
(1 row)
|
||||||
|
</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The <command>psql</command> program has a number of internal
|
||||||
|
commands that are not SQL commands. They begin the backslash
|
||||||
|
character, <quote><literal>\</literal></quote>. Some of these
|
||||||
|
commands were already listed in the welcome message. For example,
|
||||||
|
you can get help on the syntax of various
|
||||||
|
<productname>PostgreSQL</productname> <acronym>SQL</acronym>
|
||||||
commands by typing:
|
commands by typing:
|
||||||
<programlisting>
|
<screen>
|
||||||
mydb=> \h
|
<prompt>mydb=></prompt> <userinput>\h</userinput>
|
||||||
</programlisting>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Once you have finished entering your queries into the
|
To get out of <command>psql</command>, type
|
||||||
workspace, you can pass the contents of the workspace
|
<screen>
|
||||||
to the <productname>Postgres</productname> server by typing:
|
<prompt>mydb=></prompt> <userinput>\q</userinput>
|
||||||
<programlisting>
|
</screen>
|
||||||
mydb=> \g
|
and <command>psql</command> will quit and return you to your
|
||||||
</programlisting>
|
command shell. (For more internal commands, type
|
||||||
|
<literal>\?</literal> at the <command>psql</command> prompt.) The
|
||||||
This tells the server to process the query. If you
|
full capabilities of <command>psql</command> are documented in the
|
||||||
terminate your query with a semicolon, the "<literal>\g</literal>" is not
|
<citetitle>Reference Manual</citetitle>. If PostgreSQL is
|
||||||
necessary.
|
installed correctly you can also type <literal>man psql</literal>
|
||||||
<application>psql</application> will automatically process
|
at the operating system shell prompt to see the documentation. In
|
||||||
semicolon terminated queries.
|
this tutorial we will not use these features explicitly, but you
|
||||||
To read queries from a file, say myFile, instead of
|
can use them yourself when you see it fit.
|
||||||
entering them interactively, type:
|
|
||||||
<programlisting>
|
|
||||||
mydb=> \i fileName
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
To get out of <application>psql</application> and return to Unix, type
|
|
||||||
<programlisting>
|
|
||||||
mydb=> \q
|
|
||||||
</programlisting>
|
|
||||||
|
|
||||||
and <application>psql</application> will quit and return
|
|
||||||
you to your command
|
|
||||||
shell. (For more escape codes, type <command>\h</command> at the
|
|
||||||
monitor prompt.)
|
|
||||||
White space (i.e., spaces, tabs and newlines) may be
|
|
||||||
used freely in <acronym>SQL</acronym> queries. Single-line
|
|
||||||
comments are denoted by
|
|
||||||
"<literal>--</literal>". Everything after the dashes up to the end of the
|
|
||||||
line is ignored. Multiple-line comments, and comments within a line,
|
|
||||||
are denoted by "<literal>/* ... */</literal>".
|
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>Destroying a Database</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If you are the database administrator for the database
|
|
||||||
<database>mydb</database>, you can destroy it using the
|
|
||||||
following Unix command:
|
|
||||||
<programlisting>
|
|
||||||
% dropdb mydb
|
|
||||||
</programlisting>
|
|
||||||
This action physically removes all of the Unix files
|
|
||||||
associated with the database and cannot be undone, so
|
|
||||||
this should only be done with a great deal of forethought.
|
|
||||||
</para>
|
|
||||||
</sect2>
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<!-- Keep this comment at the end of the file
|
<!-- Keep this comment at the end of the file
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.14 2001/02/03 19:03:27 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.15 2001/09/02 23:27:49 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<book id="tutorial">
|
<book id="tutorial">
|
||||||
@ -10,16 +10,46 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.14 2001/02/03 19:03
|
|||||||
&legal;
|
&legal;
|
||||||
</bookinfo>
|
</bookinfo>
|
||||||
|
|
||||||
|
<preface id="tutorial-welcome">
|
||||||
|
<title>Welcome</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Welcome to <productname>PostgreSQL</productname> and the
|
||||||
|
<citetitle>PostgreSQL Tutorial</citetitle>. The following few
|
||||||
|
chapters are intended to give a simple introduction to
|
||||||
|
<productname>PostgreSQL</productname>, relational database
|
||||||
|
concepts, and the SQL language to those who are new to any one of
|
||||||
|
these aspects. We only assume some general knowledge about how to
|
||||||
|
use computers. No particular Unix or programming experience is
|
||||||
|
required.
|
||||||
|
</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
|
||||||
|
<productname>PostgreSQL</productname>.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
We hope you have a pleasant experience with
|
||||||
|
<productname>PostgreSQL</productname>.
|
||||||
|
</para>
|
||||||
|
</preface>
|
||||||
|
|
||||||
<![%single-book;[
|
<![%single-book;[
|
||||||
&intro;
|
&intro;
|
||||||
]]>
|
]]>
|
||||||
&sql;
|
|
||||||
&arch;
|
|
||||||
&start;
|
&start;
|
||||||
&query;
|
&query;
|
||||||
&advanced;
|
&advanced;
|
||||||
<![%single-book;[
|
<![%single-book;[
|
||||||
&biblio;
|
&biblio;
|
||||||
|
&bookindex;
|
||||||
]]>
|
]]>
|
||||||
|
|
||||||
</book>
|
</book>
|
||||||
|
@ -1,19 +1,18 @@
|
|||||||
---------------------------------------------------------------------------
|
---------------------------------------------------------------------------
|
||||||
--
|
--
|
||||||
-- advanced.sql-
|
-- advanced.sql-
|
||||||
-- more POSTGRES SQL features. (These are not part of the SQL-92
|
-- Tutorial on advanced more PostgreSQL features
|
||||||
-- standard.)
|
|
||||||
--
|
--
|
||||||
--
|
--
|
||||||
-- Copyright (c) 1994, Regents of the University of California
|
-- Copyright (c) 1994, Regents of the University of California
|
||||||
--
|
--
|
||||||
-- $Id: advanced.source,v 1.3 1999/07/08 15:28:51 momjian Exp $
|
-- $Id: advanced.source,v 1.4 2001/09/02 23:27:50 petere Exp $
|
||||||
--
|
--
|
||||||
---------------------------------------------------------------------------
|
---------------------------------------------------------------------------
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Inheritance:
|
-- Inheritance:
|
||||||
-- a table can inherit from zero or more tables. A query can reference
|
-- S table can inherit from zero or more tables. A query can reference
|
||||||
-- either all rows of a table or all rows of a table plus all of its
|
-- either all rows of a table or all rows of a table plus all of its
|
||||||
-- descendants.
|
-- descendants.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
@ -31,7 +30,7 @@ CREATE TABLE capitals (
|
|||||||
state char(2)
|
state char(2)
|
||||||
) INHERITS (cities);
|
) INHERITS (cities);
|
||||||
|
|
||||||
-- now, let's populate the tables
|
-- Now, let's populate the tables.
|
||||||
INSERT INTO cities VALUES ('San Francisco', 7.24E+5, 63);
|
INSERT INTO cities VALUES ('San Francisco', 7.24E+5, 63);
|
||||||
INSERT INTO cities VALUES ('Las Vegas', 2.583E+5, 2174);
|
INSERT INTO cities VALUES ('Las Vegas', 2.583E+5, 2174);
|
||||||
INSERT INTO cities VALUES ('Mariposa', 1200, 1953);
|
INSERT INTO cities VALUES ('Mariposa', 1200, 1953);
|
||||||
@ -56,72 +55,6 @@ FROM cities* c
|
|||||||
WHERE c.altitude > 500;
|
WHERE c.altitude > 500;
|
||||||
|
|
||||||
|
|
||||||
-----------------------------
|
|
||||||
-- Time Travel:
|
|
||||||
-- this feature allows you to run historical queries.
|
|
||||||
-- removed for v6.3, but possible using triggers.
|
|
||||||
-- see contrib/spi/README for more information.
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
-- first, let's make some changes to the cities table (suppose Mariposa's
|
|
||||||
-- population grows 10% this year)
|
|
||||||
|
|
||||||
-- UPDATE cities
|
|
||||||
-- SET population = population * 1.1
|
|
||||||
-- WHERE name = 'Mariposa';
|
|
||||||
|
|
||||||
-- the default time is the current time ('now'):
|
|
||||||
|
|
||||||
-- SELECT * FROM cities WHERE name = 'Mariposa';
|
|
||||||
|
|
||||||
-- we can also retrieve the population of Mariposa ever has. ('epoch' is the
|
|
||||||
-- earliest time representable by the system)
|
|
||||||
|
|
||||||
-- SELECT name, population
|
|
||||||
-- FROM cities['epoch', 'now'] -- can be abbreviated to cities[,]
|
|
||||||
-- WHERE name = 'Mariposa';
|
|
||||||
|
|
||||||
|
|
||||||
----------------------
|
|
||||||
-- Arrays:
|
|
||||||
-- attributes can be arrays of base types or user-defined types
|
|
||||||
----------------------
|
|
||||||
|
|
||||||
CREATE TABLE sal_emp (
|
|
||||||
name text,
|
|
||||||
pay_by_quarter int4[],
|
|
||||||
schedule text[][]
|
|
||||||
);
|
|
||||||
|
|
||||||
-- insert instances with array attributes. Note the use of braces
|
|
||||||
|
|
||||||
INSERT INTO sal_emp VALUES (
|
|
||||||
'Bill',
|
|
||||||
'{10000,10000,10000,10000}',
|
|
||||||
'{{"meeting", "lunch"}, {}}');
|
|
||||||
|
|
||||||
INSERT INTO sal_emp VALUES (
|
|
||||||
'Carol',
|
|
||||||
'{20000,25000,25000,25000}',
|
|
||||||
'{{"talk", "consult"}, {"meeting"}}');
|
|
||||||
|
|
||||||
----------------------
|
|
||||||
-- queries on array attributes
|
|
||||||
----------------------
|
|
||||||
SELECT name FROM sal_emp WHERE
|
|
||||||
sal_emp.pay_by_quarter[1] <> sal_emp.pay_by_quarter[2];
|
|
||||||
|
|
||||||
-- retrieve third quarter pay of all employees
|
|
||||||
|
|
||||||
SELECT sal_emp.pay_by_quarter[3] FROM sal_emp;
|
|
||||||
|
|
||||||
-- select subarrays
|
|
||||||
|
|
||||||
SELECT sal_emp.schedule[1:2][1:1] FROM sal_emp WHERE
|
|
||||||
sal_emp.name = 'Bill';
|
|
||||||
|
|
||||||
|
|
||||||
-- clean up (you must remove the children first)
|
-- clean up (you must remove the children first)
|
||||||
DROP TABLE sal_emp;
|
|
||||||
DROP TABLE capitals;
|
DROP TABLE capitals;
|
||||||
DROP TABLE cities;
|
DROP TABLE cities;
|
||||||
|
@ -6,22 +6,22 @@
|
|||||||
--
|
--
|
||||||
-- Copyright (c) 1994, Andrew Yu, University of California
|
-- Copyright (c) 1994, Andrew Yu, University of California
|
||||||
--
|
--
|
||||||
-- $Id: basics.source,v 1.3 1999/07/08 15:27:01 momjian Exp $
|
-- $Id: basics.source,v 1.4 2001/09/02 23:27:50 petere Exp $
|
||||||
--
|
--
|
||||||
---------------------------------------------------------------------------
|
---------------------------------------------------------------------------
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Creating a table:
|
-- Creating a New Table:
|
||||||
-- a CREATE TABLE is used to create base tables. POSTGRES SQL has
|
-- A CREATE TABLE is used to create base tables. PostgreSQL has
|
||||||
-- its own set of built-in types. (Note that keywords are case-
|
-- its own set of built-in types. (Note that SQL is case-
|
||||||
-- insensitive but identifiers are case-sensitive.)
|
-- insensitive.)
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
CREATE TABLE weather (
|
CREATE TABLE weather (
|
||||||
city varchar(80),
|
city varchar(80),
|
||||||
temp_lo int, -- low temperature
|
temp_lo int, -- low temperature
|
||||||
temp_hi int, -- high temperature
|
temp_hi int, -- high temperature
|
||||||
prcp float8, -- precipitation
|
prcp real, -- precipitation
|
||||||
date date
|
date date
|
||||||
);
|
);
|
||||||
|
|
||||||
@ -30,97 +30,104 @@ CREATE TABLE cities (
|
|||||||
location point
|
location point
|
||||||
);
|
);
|
||||||
|
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Inserting data:
|
-- Populating a Table With Rows:
|
||||||
-- an INSERT statement is used to insert a new row into a table. There
|
-- An INSERT statement is used to insert a new row into a table. There
|
||||||
-- are several ways you can specify what columns the data should go to.
|
-- are several ways you can specify what columns the data should go to.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
-- 1. the simplest case is when the list of value correspond to the order of
|
-- 1. The simplest case is when the list of value correspond to the order of
|
||||||
-- the columns specified in CREATE TABLE.
|
-- the columns specified in CREATE TABLE.
|
||||||
|
|
||||||
INSERT INTO weather
|
INSERT INTO weather
|
||||||
VALUES ('San Francisco', 46, 50, 0.25, '11/27/1994');
|
VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');
|
||||||
|
|
||||||
INSERT INTO cities
|
INSERT INTO cities
|
||||||
VALUES ('San Francisco', '(-194.0, 53.0)');
|
VALUES ('San Francisco', '(-194.0, 53.0)');
|
||||||
|
|
||||||
-- 2. you can also specify what column the values correspond to. (The columns
|
-- 2. You can also specify what column the values correspond to. (The columns
|
||||||
-- can be specified in any order. You may also omit any number of columns.
|
-- can be specified in any order. You may also omit any number of columns,
|
||||||
-- eg. unknown precipitation below)
|
-- e.g., unknown precipitation below.
|
||||||
|
|
||||||
INSERT INTO weather (city, temp_lo, temp_hi, prcp, date)
|
INSERT INTO weather (city, temp_lo, temp_hi, prcp, date)
|
||||||
VALUES ('San Francisco', 43, 57, 0.0, '11/29/1994');
|
VALUES ('San Francisco', 43, 57, 0.0, '1994-11-29');
|
||||||
|
|
||||||
INSERT INTO weather (date, city, temp_hi, temp_lo)
|
INSERT INTO weather (date, city, temp_hi, temp_lo)
|
||||||
VALUES ('11/29/1994', 'Hayward', 54, 37);
|
VALUES ('1994-11-29', 'Hayward', 54, 37);
|
||||||
|
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Retrieving data:
|
-- Querying a Table:
|
||||||
-- a SELECT statement is used for retrieving data. The basic syntax is
|
-- A SELECT statement is used for retrieving data. The basic syntax is
|
||||||
-- SELECT columns FROM tables WHERE predicates
|
-- SELECT columns FROM tables WHERE predicates.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
-- a simple one would be
|
-- A simple one would be:
|
||||||
|
|
||||||
SELECT * FROM weather;
|
SELECT * FROM weather;
|
||||||
|
|
||||||
-- you may also specify expressions in the target list (the 'AS column'
|
-- You may also specify expressions in the target list. (The 'AS column'
|
||||||
-- specifies the column name of the result. It is optional.)
|
-- specifies the column name of the result. It is optional.)
|
||||||
|
|
||||||
SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
|
SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
|
||||||
|
|
||||||
-- if you want to retrieve rows that satisfy certain condition (ie. a
|
-- If you want to retrieve rows that satisfy certain condition (i.e., a
|
||||||
-- restriction), specify the condition in WHERE. The following retrieves
|
-- restriction), specify the condition in WHERE. The following retrieves
|
||||||
-- the weather of San Francisco on rainy days.
|
-- the weather of San Francisco on rainy days.
|
||||||
|
|
||||||
SELECT *
|
SELECT *
|
||||||
FROM weather
|
FROM weather
|
||||||
WHERE city = 'San Francisco'
|
WHERE city = 'San Francisco'
|
||||||
and prcp > 0.0;
|
AND prcp > 0.0;
|
||||||
|
|
||||||
-- here is a more complicated one. Duplicates are removed when DISTINCT is
|
-- Here is a more complicated one. Duplicates are removed when DISTINCT is
|
||||||
-- specified. ORDER BY specifies the column to sort on. (Just to make sure the
|
-- specified. ORDER BY specifies the column to sort on. (Just to make sure the
|
||||||
-- following won't confuse you, DISTINCT and ORDER BY can be used separately.)
|
-- following won't confuse you, DISTINCT and ORDER BY can be used separately.)
|
||||||
|
|
||||||
SELECT DISTINCT city
|
SELECT DISTINCT city
|
||||||
FROM weather
|
FROM weather
|
||||||
ORDER BY city;
|
ORDER BY city;
|
||||||
|
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Retrieving data into other classes:
|
-- Joins Between Tables:
|
||||||
-- a SELECT ... INTO statement can be used to retrieve data into
|
|
||||||
-- another class.
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
SELECT * INTO TABLE mytemp
|
|
||||||
FROM weather
|
|
||||||
WHERE city = 'San Francisco'
|
|
||||||
and prcp > 0.0;
|
|
||||||
|
|
||||||
SELECT * from mytemp;
|
|
||||||
|
|
||||||
-----------------------------
|
|
||||||
-- Aggregates
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
SELECT max(temp_lo)
|
|
||||||
FROM weather;
|
|
||||||
|
|
||||||
-- Aggregate with GROUP BY
|
|
||||||
SELECT city, max(temp_lo)
|
|
||||||
FROM weather
|
|
||||||
GROUP BY city;
|
|
||||||
|
|
||||||
-----------------------------
|
|
||||||
-- Joining tables:
|
|
||||||
-- queries can access multiple tables at once or access the same table
|
-- queries can access multiple tables at once or access the same table
|
||||||
-- in such a way that multiple instances of the table are being processed
|
-- in such a way that multiple instances of the table are being processed
|
||||||
-- at the same time.
|
-- at the same time.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
-- suppose we want to find all the records that are in the temperature range
|
-- The following joins the weather table and the cities table.
|
||||||
|
|
||||||
|
SELECT *
|
||||||
|
FROM weather, cities
|
||||||
|
WHERE city = name;
|
||||||
|
|
||||||
|
-- This prevents a duplicate city name column:
|
||||||
|
|
||||||
|
SELECT city, temp_lo, temp_hi, prcp, date, location
|
||||||
|
FROM weather, cities
|
||||||
|
WHERE city = name;
|
||||||
|
|
||||||
|
-- since the column names are all different, we don't have to specify the
|
||||||
|
-- table name. If you want to be clear, you can do the following. They give
|
||||||
|
-- identical results, of course.
|
||||||
|
|
||||||
|
SELECT weather.city, weather.temp_lo, weather.temp_hi, weather.prcp, weather.date, cities.location
|
||||||
|
FROM weather, cities
|
||||||
|
WHERE cities.name = weather.city;
|
||||||
|
|
||||||
|
-- JOIN syntax
|
||||||
|
|
||||||
|
SELECT *
|
||||||
|
FROM weather JOIN cities ON (weather.city = cities.name);
|
||||||
|
|
||||||
|
-- Outer join
|
||||||
|
|
||||||
|
SELECT *
|
||||||
|
FROM weather LEFT OUTER JOIN cities ON (weather.city = cities.name);
|
||||||
|
|
||||||
|
-- Suppose we want to find all the records that are in the temperature range
|
||||||
-- of other records. W1 and W2 are aliases for weather.
|
-- of other records. W1 and W2 are aliases for weather.
|
||||||
|
|
||||||
SELECT W1.city, W1.temp_lo, W1.temp_hi,
|
SELECT W1.city, W1.temp_lo, W1.temp_hi,
|
||||||
@ -129,55 +136,64 @@ FROM weather W1, weather W2
|
|||||||
WHERE W1.temp_lo < W2.temp_lo
|
WHERE W1.temp_lo < W2.temp_lo
|
||||||
and W1.temp_hi > W2.temp_hi;
|
and W1.temp_hi > W2.temp_hi;
|
||||||
|
|
||||||
-- let's join two tables. The following joins the weather table
|
|
||||||
-- and the cities table.
|
|
||||||
|
|
||||||
SELECT city, location, prcp, date
|
|
||||||
FROM weather, cities
|
|
||||||
WHERE name = city;
|
|
||||||
|
|
||||||
-- since the column names are all different, we don't have to specify the
|
|
||||||
-- table name. If you want to be clear, you can do the following. They give
|
|
||||||
-- identical results, of course.
|
|
||||||
|
|
||||||
SELECT w.city, c.location, w.prcp, w.date
|
|
||||||
FROM weather w, cities c
|
|
||||||
WHERE c.name = w.city;
|
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Updating data:
|
-- Aggregate Functions
|
||||||
-- an UPDATE statement is used for updating data.
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
-- suppose you discover the temperature readings are all off by 2 degrees as
|
SELECT max(temp_lo)
|
||||||
|
FROM weather;
|
||||||
|
|
||||||
|
SELECT city FROM weather
|
||||||
|
WHERE temp_lo = (SELECT max(temp_lo) FROM weather);
|
||||||
|
|
||||||
|
-- Aggregate with GROUP BY
|
||||||
|
SELECT city, max(temp_lo)
|
||||||
|
FROM weather
|
||||||
|
GROUP BY city;
|
||||||
|
|
||||||
|
-- ... and HAVING
|
||||||
|
SELECT city, max(temp_lo)
|
||||||
|
FROM weather
|
||||||
|
GROUP BY city
|
||||||
|
HAVING max(temp_lo) < 40;
|
||||||
|
|
||||||
|
|
||||||
|
-----------------------------
|
||||||
|
-- Updates:
|
||||||
|
-- An UPDATE statement is used for updating data.
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
-- Suppose you discover the temperature readings are all off by 2 degrees as
|
||||||
-- of Nov 28, you may update the data as follow:
|
-- of Nov 28, you may update the data as follow:
|
||||||
|
|
||||||
UPDATE weather
|
UPDATE weather
|
||||||
SET temp_hi = temp_hi - 2, temp_lo = temp_lo - 2
|
SET temp_hi = temp_hi - 2, temp_lo = temp_lo - 2
|
||||||
WHERE date > '11/28/1994';
|
WHERE date > '1994-11-28';
|
||||||
|
|
||||||
SELECT * from weather;
|
SELECT * FROM weather;
|
||||||
|
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Deleting data:
|
-- Deletions:
|
||||||
-- a DELETE statement is used for deleting rows from a table.
|
-- A DELETE statement is used for deleting rows from a table.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
-- suppose you are no longer interested in the weather of Hayward, you can
|
-- Suppose you are no longer interested in the weather of Hayward, then you can
|
||||||
-- do the following to delete those rows from the table
|
-- do the following to delete those rows from the table.
|
||||||
|
|
||||||
DELETE FROM weather WHERE city = 'Hayward';
|
DELETE FROM weather WHERE city = 'Hayward';
|
||||||
|
|
||||||
SELECT * from weather;
|
SELECT * FROM weather;
|
||||||
|
|
||||||
-- you can also delete all the rows in a table by doing the following. (This
|
-- You can also delete all the rows in a table by doing the following. (This
|
||||||
-- is different from DROP TABLE which removes the table in addition to the
|
-- is different from DROP TABLE which removes the table in addition to the
|
||||||
-- removing the rows.)
|
-- removing the rows.)
|
||||||
|
|
||||||
DELETE FROM weather;
|
DELETE FROM weather;
|
||||||
|
|
||||||
SELECT * from weather;
|
SELECT * FROM weather;
|
||||||
|
|
||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
-- Removing the tables:
|
-- Removing the tables:
|
||||||
@ -185,4 +201,4 @@ SELECT * from weather;
|
|||||||
-- can no longer use those tables.
|
-- can no longer use those tables.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
DROP TABLE weather, cities, mytemp;
|
DROP TABLE weather, cities;
|
||||||
|
Loading…
Reference in New Issue
Block a user