Terminology cleanup: class -> table, instance -> row, attribute -> column,
etc.
This commit is contained in:
parent
0651a5799d
commit
027f144e39
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.28 2000/11/24 17:44:21 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.29 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<book id="admin">
|
||||
@ -35,7 +35,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.28 2000/11/24 17:44:21
|
||||
developed originally in the UC Berkeley Computer Science Department,
|
||||
pioneered many of the object-relational concepts
|
||||
now becoming available in some commercial databases.
|
||||
It provides SQL92/SQL3 language support,
|
||||
It provides SQL92/SQL99 language support,
|
||||
transaction integrity, and type extensibility.
|
||||
<productname>PostgreSQL</productname> is an open-source descendant
|
||||
of this original Berkeley code.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.20 2001/01/05 06:34:15 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.21 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced">
|
||||
@ -22,14 +22,14 @@ $Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.20 2001/01/05 06:34:15 tg
|
||||
<title>Inheritance</title>
|
||||
|
||||
<para>
|
||||
Let's create two classes. The capitals class contains
|
||||
Let's create two tables. The capitals table contains
|
||||
state capitals that are also cities. Naturally, the
|
||||
capitals class should inherit from cities.
|
||||
capitals table should inherit from cities.
|
||||
|
||||
<programlisting>
|
||||
CREATE TABLE cities (
|
||||
name text,
|
||||
population float,
|
||||
population real,
|
||||
altitude int -- (in ft)
|
||||
);
|
||||
|
||||
@ -38,20 +38,19 @@ CREATE TABLE capitals (
|
||||
) INHERITS (cities);
|
||||
</programlisting>
|
||||
|
||||
In this case, an instance of capitals <firstterm>inherits</firstterm> all
|
||||
attributes (name, population, and altitude) from its
|
||||
parent, cities. The type of the attribute name is
|
||||
In this case, a row of capitals <firstterm>inherits</firstterm> all
|
||||
columns (name, population, and altitude) from its
|
||||
parent, cities. The type of the column name is
|
||||
<type>text</type>, a native <productname>Postgres</productname>
|
||||
type for variable length
|
||||
ASCII strings. The type of the attribute population is
|
||||
<type>float</type>, a native <productname>Postgres</productname>
|
||||
type for double precision
|
||||
ASCII strings. The type of the column population is
|
||||
<type>real</type>, a type for single precision
|
||||
floating point numbers. State capitals have an extra
|
||||
attribute, state, that shows their state.
|
||||
column, state, that shows their state.
|
||||
In <productname>Postgres</productname>,
|
||||
a class can inherit from zero or more other classes,
|
||||
and a query can reference either all instances of a
|
||||
class or all instances of a class plus all of its
|
||||
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>
|
||||
@ -109,7 +108,7 @@ SELECT name, altitude
|
||||
|
||||
<para>
|
||||
Here the <quote>ONLY</quote> before cities indicates that the query should
|
||||
be run over only the cities table, and not classes below cities in the
|
||||
be run over only the cities table, and not tables below cities in the
|
||||
inheritance hierarchy. Many of the commands that we
|
||||
have already discussed -- <command>SELECT</command>,
|
||||
<command>UPDATE</command> and <command>DELETE</command> --
|
||||
@ -122,7 +121,7 @@ SELECT name, altitude
|
||||
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-classes you append "*" to the table name.
|
||||
syntax, to get the sub-tables you append "*" to the table name.
|
||||
For example
|
||||
<programlisting>
|
||||
SELECT * from cities*;
|
||||
@ -147,11 +146,11 @@ SET SQL_Inheritance TO OFF;
|
||||
|
||||
<para>
|
||||
One of the tenets of the relational model is that the
|
||||
attributes of a relation are atomic.
|
||||
columns of a table are atomic.
|
||||
<productname>Postgres</productname> does not
|
||||
have this restriction; attributes can themselves contain
|
||||
have this restriction; columns can themselves contain
|
||||
sub-values that can be accessed from the query
|
||||
language. For example, you can create attributes that
|
||||
language. For example, you can create columns that
|
||||
are arrays of base types.
|
||||
</para>
|
||||
|
||||
@ -159,26 +158,26 @@ SET SQL_Inheritance TO OFF;
|
||||
<title>Arrays</title>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</productname> allows attributes of an
|
||||
instance to be defined
|
||||
<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
|
||||
class with arrays of base types.
|
||||
table with arrays of base types.
|
||||
|
||||
<programlisting>
|
||||
CREATE TABLE SAL_EMP (
|
||||
name text,
|
||||
pay_by_quarter int4[],
|
||||
pay_by_quarter integer[],
|
||||
schedule text[][]
|
||||
);
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The above query will create a class named SAL_EMP with
|
||||
The above query will create a table named SAL_EMP with
|
||||
a <firstterm>text</firstterm> string (name), a one-dimensional
|
||||
array of <firstterm>int4</firstterm>
|
||||
array of <firstterm>integer</firstterm>
|
||||
(pay_by_quarter), which represents the employee's
|
||||
salary by quarter and a two-dimensional array of
|
||||
<firstterm>text</firstterm>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.8 2000/12/18 23:39:37 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="arrays">
|
||||
@ -14,10 +14,10 @@ This must become a chapter on array behavior. Volunteers? - thomas 1998-01-12
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
<ProductName>Postgres</ProductName> allows attributes of a class
|
||||
<ProductName>Postgres</ProductName> allows columns of a table
|
||||
to be defined as variable-length multi-dimensional
|
||||
arrays. Arrays of any built-in type or user-defined type
|
||||
can be created. To illustrate their use, we create this class:
|
||||
can be created. To illustrate their use, we create this table:
|
||||
|
||||
<ProgramListing>
|
||||
CREATE TABLE sal_emp (
|
||||
@ -29,7 +29,7 @@ CREATE TABLE sal_emp (
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
The above query will create a class named <FirstTerm>sal_emp</FirstTerm> with
|
||||
The above query will create a table named <FirstTerm>sal_emp</FirstTerm> with
|
||||
a <FirstTerm>text</FirstTerm> string (name), a one-dimensional array of <FirstTerm>int4</FirstTerm>
|
||||
(pay_by_quarter), which represents the employee's
|
||||
salary by quarter, and a two-dimensional array of <FirstTerm>text</FirstTerm>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="extend">
|
||||
@ -44,15 +44,15 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
about databases, tables, columns, etc., in what are
|
||||
commonly known as system catalogs. (Some systems call
|
||||
this the data dictionary). The catalogs appear to the
|
||||
user as classes, like any other, but the <acronym>DBMS</acronym> stores
|
||||
user as tables like any other, but the <acronym>DBMS</acronym> stores
|
||||
its internal bookkeeping in them. One key difference
|
||||
between <productname>Postgres</productname> and standard relational systems is
|
||||
that <productname>Postgres</productname> stores much more information in its
|
||||
catalogs -- not only information about tables and columns,
|
||||
but also information about its types, functions, access
|
||||
methods, and so on. These classes can be modified by
|
||||
methods, and so on. These tables can be modified by
|
||||
the user, and since <productname>Postgres</productname> bases its internal operation
|
||||
on these classes, this means that <productname>Postgres</productname> can be
|
||||
on these tables, this means that <productname>Postgres</productname> can be
|
||||
extended by users. By comparison, conventional
|
||||
database systems can only be extended by changing hardcoded
|
||||
procedures within the <acronym>DBMS</acronym> or by loading modules
|
||||
@ -87,13 +87,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
by the user and only understands the behavior of such
|
||||
types to the extent that the user describes them.
|
||||
Composite types are created whenever the user creates a
|
||||
class. EMP is an example of a composite type.
|
||||
table. EMP is an example of a composite type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</productname> stores these types
|
||||
in only one way (within the
|
||||
file that stores all instances of the class) but the
|
||||
file that stores all rows of a table) but the
|
||||
user can "look inside" at the attributes of these types
|
||||
from the query language and optimize their retrieval by
|
||||
(for example) defining indices on the attributes.
|
||||
@ -119,7 +119,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
reference.
|
||||
All system catalogs have names that begin with
|
||||
<firstterm>pg_</firstterm>.
|
||||
The following classes contain information that may be
|
||||
The following tables contain information that may be
|
||||
useful to the end user. (There are many other system
|
||||
catalogs, but there should rarely be a reason to query
|
||||
them directly.)
|
||||
@ -141,11 +141,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_class</entry>
|
||||
<entry> classes</entry>
|
||||
<entry> tables</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_attribute</entry>
|
||||
<entry> class attributes</entry>
|
||||
<entry> table columns</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_index</entry>
|
||||
@ -195,10 +195,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
</figure>
|
||||
|
||||
The Reference Manual gives a more detailed explanation
|
||||
of these catalogs and their attributes. However,
|
||||
of these catalogs and their columns. However,
|
||||
<xref linkend="EXTEND-CATALOGS">
|
||||
shows the major entities and their relationships
|
||||
in the system catalogs. (Attributes that do not refer
|
||||
in the system catalogs. (Columns that do not refer
|
||||
to other entities are not shown unless they are part of
|
||||
a primary key.)
|
||||
This diagram is more or less incomprehensible until you
|
||||
@ -216,13 +216,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
some of these join queries (which are often
|
||||
three- or four-way joins) more understandable,
|
||||
because you will be able to see that the
|
||||
attributes used in the queries form foreign keys
|
||||
in other classes.
|
||||
columns used in the queries form foreign keys
|
||||
in other tables.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Many different features (classes, attributes,
|
||||
Many different features (tables, columns,
|
||||
functions, types, access methods, etc.) are
|
||||
tightly integrated in this schema. A simple
|
||||
create command may modify many of these catalogs.
|
||||
@ -241,15 +241,15 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.8 2000/12/26 00:10:37 peter
|
||||
</note>
|
||||
|
||||
Nearly every catalog contains some reference to
|
||||
instances in one or both of these classes. For
|
||||
rows in one or both of these tables. For
|
||||
example, <productname>Postgres</productname> frequently uses type
|
||||
signatures (e.g., of functions and operators) to
|
||||
identify unique instances of other catalogs.
|
||||
identify unique rows of other catalogs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
There are many attributes and relationships that
|
||||
There are many columns and relationships that
|
||||
have obvious meanings, but there are many
|
||||
(particularly those that have to do with access
|
||||
methods) that do not. The relationships between
|
||||
|
@ -35,7 +35,7 @@
|
||||
<para>
|
||||
For a <firstterm>functional index</firstterm>, an index is defined
|
||||
on the result of a function applied
|
||||
to one or more attributes of a single class.
|
||||
to one or more columns of a single table.
|
||||
This is a single-column index (namely, the function result)
|
||||
even if the function uses more than one input field.
|
||||
Functional indices can be used to obtain fast access to data
|
||||
|
@ -1,14 +1,14 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.12 2001/01/05 06:34:15 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="inherit">
|
||||
<title>Inheritance</title>
|
||||
|
||||
<para>
|
||||
Let's create two classes. The capitals class contains
|
||||
Let's create two tables. The capitals table contains
|
||||
state capitals which are also cities. Naturally, the
|
||||
capitals class should inherit from cities.
|
||||
capitals table should inherit from cities.
|
||||
|
||||
<programlisting>
|
||||
CREATE TABLE cities (
|
||||
@ -22,7 +22,7 @@ CREATE TABLE capitals (
|
||||
) INHERITS (cities);
|
||||
</programlisting>
|
||||
|
||||
In this case, an instance of capitals <firstterm>inherits</firstterm> all
|
||||
In this case, a row of capitals <firstterm>inherits</firstterm> all
|
||||
attributes (name, population, and altitude) from its
|
||||
parent, cities. The type of the attribute name is
|
||||
<type>text</type>, a native <productname>Postgres</productname> type for variable length
|
||||
@ -30,9 +30,9 @@ CREATE TABLE capitals (
|
||||
<type>float</type>, a native <productname>Postgres</productname> type for double precision
|
||||
floating point numbers. State capitals have an extra
|
||||
attribute, state, that shows their state. In <productname>Postgres</productname>,
|
||||
a class can inherit from zero or more other classes,
|
||||
and a query can reference either all instances of a
|
||||
class or all instances of a class plus all of its
|
||||
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 table plus all of its
|
||||
descendants.
|
||||
|
||||
<note>
|
||||
@ -90,7 +90,7 @@ SELECT name, altitude
|
||||
|
||||
<para>
|
||||
Here the <quote>ONLY</quote> before cities indicates that the query should
|
||||
be run over only cities and not classes below cities in the
|
||||
be run over only cities and not tables below cities in the
|
||||
inheritance hierarchy. Many of the commands that we
|
||||
have already discussed -- <command>SELECT</command>,
|
||||
<command>UPDATE</command> and <command>DELETE</command> --
|
||||
@ -99,7 +99,7 @@ SELECT name, altitude
|
||||
|
||||
<para>
|
||||
In some cases you may wish to know which table a particular tuple
|
||||
originated from. There is a system attribute called
|
||||
originated from. There is a system column called
|
||||
<quote>TABLEOID</quote> in each table which can tell you the
|
||||
originating table:
|
||||
|
||||
@ -153,7 +153,7 @@ SELECT name, altitude
|
||||
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-classes you append "*" to the table name.
|
||||
syntax, to get the sub-tables you append "*" to the table name.
|
||||
For example
|
||||
<programlisting>
|
||||
SELECT * from cities*;
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.12 2000/09/29 20:21:34 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="intro">
|
||||
@ -44,7 +44,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.12 2000/09/29 20:21:34 peter
|
||||
extend the system:
|
||||
|
||||
<simplelist>
|
||||
<member>classes</member>
|
||||
<member>tables</member>
|
||||
<member>inheritance</member>
|
||||
<member>types</member>
|
||||
<member>functions</member>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.22 2000/12/26 00:10:37 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.23 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpqplusplus">
|
||||
@ -353,7 +353,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.22 2000/12/26 00:10:
|
||||
<listitem>
|
||||
<para>
|
||||
<function>Tuples</function>
|
||||
Returns the number of tuples (instances) in the query result.
|
||||
Returns the number of tuples (rows) in the query result.
|
||||
<synopsis>
|
||||
int PgDatabase::Tuples()
|
||||
</synopsis>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.54 2000/12/28 00:16:11 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.55 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq-chapter">
|
||||
@ -810,7 +810,7 @@ when you want to know the status from the latest operation on the connection.
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQntuples</function>
|
||||
Returns the number of tuples (instances)
|
||||
Returns the number of tuples (rows)
|
||||
in the query result.
|
||||
<synopsis>
|
||||
int PQntuples(const PGresult *res);
|
||||
@ -2042,7 +2042,7 @@ main()
|
||||
PQclear(res);
|
||||
|
||||
/*
|
||||
* fetch instances from the pg_database, the system catalog of
|
||||
* fetch rows from the pg_database, the system catalog of
|
||||
* databases
|
||||
*/
|
||||
res = PQexec(conn, "DECLARE mycursor CURSOR FOR select * from pg_database");
|
||||
@ -2067,7 +2067,7 @@ main()
|
||||
printf("%-15s", PQfname(res, i));
|
||||
printf("\n\n");
|
||||
|
||||
/* next, print out the instances */
|
||||
/* next, print out the rows */
|
||||
for (i = 0; i < PQntuples(res); i++)
|
||||
{
|
||||
for (j = 0; j < nFields; j++)
|
||||
@ -2315,7 +2315,7 @@ main()
|
||||
PQclear(res);
|
||||
|
||||
/*
|
||||
* fetch instances from the pg_database, the system catalog of
|
||||
* fetch rows from the pg_database, the system catalog of
|
||||
* databases
|
||||
*/
|
||||
res = PQexec(conn, "DECLARE mycursor BINARY CURSOR FOR select * from test1");
|
||||
|
@ -10,7 +10,7 @@ A description of the database file default page format.
|
||||
|
||||
<para>
|
||||
This section provides an overview of the page format used by <productname>Postgres</productname>
|
||||
classes. User-defined access methods need not use this page format.
|
||||
tables. User-defined access methods need not use this page format.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -18,13 +18,13 @@ In the following explanation, a
|
||||
<firstterm>byte</firstterm>
|
||||
is assumed to contain 8 bits. In addition, the term
|
||||
<firstterm>item</firstterm>
|
||||
refers to data that is stored in <productname>Postgres</productname> classes.
|
||||
refers to data that is stored in <productname>Postgres</productname> tables.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following table shows how pages in both normal <productname>Postgres</productname> classes
|
||||
and <productname>Postgres</productname> index
|
||||
classes (e.g., a B-tree index) are structured.
|
||||
The following table shows how pages in both normal <productname>Postgres</productname> tables
|
||||
and <productname>Postgres</productname> indices
|
||||
(e.g., a B-tree index) are structured.
|
||||
|
||||
<table tocentry="1">
|
||||
<title>Sample Page Layout</title>
|
||||
@ -141,7 +141,7 @@ access method. The last 2 bytes of the page header,
|
||||
encode the page size and information on the internal fragmentation of
|
||||
the page. Page size is stored in each page because frames in the
|
||||
buffer pool may be subdivided into equal sized pages on a frame by
|
||||
frame basis within a class. The internal fragmentation information is
|
||||
frame basis within a table. The internal fragmentation information is
|
||||
used to aid in determining when page reorganization should occur.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.13 2001/01/09 15:26:16 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.14 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plsql">
|
||||
@ -181,12 +181,12 @@ END;
|
||||
|
||||
<varlistentry>
|
||||
<term>
|
||||
<replaceable>name</replaceable> <replaceable>class</replaceable>%ROWTYPE;
|
||||
<replaceable>name</replaceable> <replaceable>table</replaceable>%ROWTYPE;
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Declares a row with the structure of the given class. Class must be
|
||||
an existing table- or view name of the database. The fields of the row
|
||||
Declares a row with the structure of the given table. <replaceable>table</replaceable> must be
|
||||
an existing table or view name of the database. The fields of the row
|
||||
are accessed in the dot notation. Parameters to a function can
|
||||
be composite types (complete table rows). In that case, the
|
||||
corresponding identifier $n will be a rowtype, but it
|
||||
@ -281,7 +281,7 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<replaceable>class.field</replaceable>%TYPE
|
||||
<replaceable>table.field</replaceable>%TYPE
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -292,12 +292,12 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
|
||||
same function, that is visible at this point.
|
||||
</para>
|
||||
<para>
|
||||
<replaceable>class</replaceable> is the name of an existing table
|
||||
<replaceable>table</replaceable> is the name of an existing table
|
||||
or view where <replaceable>field</replaceable> is the name of
|
||||
an attribute.
|
||||
</para>
|
||||
<para>
|
||||
Using the <replaceable>class.field</replaceable>%TYPE
|
||||
Using the <replaceable>table.field</replaceable>%TYPE
|
||||
causes PL/pgSQL to look up the attributes definitions at the
|
||||
first call to the function during the lifetime of a backend.
|
||||
Have a table with a char(20) attribute and some PL/pgSQL functions
|
||||
@ -307,7 +307,7 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
|
||||
char(40) and restores the data. Ha - he forgot about the
|
||||
functions. The computations inside them will truncate the values
|
||||
to 20 characters. But if they are defined using the
|
||||
<replaceable>class.field</replaceable>%TYPE
|
||||
<replaceable>table.field</replaceable>%TYPE
|
||||
declarations, they will automagically handle the size change or
|
||||
if the new table schema defines the attribute as text type.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.30 2001/01/12 22:15:32 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.31 2001/01/13 23:58:55 petere Exp $
|
||||
|
||||
PostgreSQL Programmer's Guide.
|
||||
-->
|
||||
@ -35,7 +35,7 @@ PostgreSQL Programmer's Guide.
|
||||
developed originally in the UC Berkeley Computer Science Department,
|
||||
pioneered many of the object-relational concepts
|
||||
now becoming available in some commercial databases.
|
||||
It provides SQL92/SQL3 language support,
|
||||
It provides SQL92/SQL99 language support,
|
||||
transaction integrity, and type extensibility.
|
||||
<productname>PostgreSQL</productname> is an
|
||||
open-source descendant of this original Berkeley code.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.16 2000/12/22 19:31:56 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.17 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="query">
|
||||
@ -7,8 +7,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.16 2000/12/22 19:31:56 peter
|
||||
|
||||
<para>
|
||||
The <productname>Postgres</productname> query language is a variant of
|
||||
the <acronym>SQL3</acronym> draft next-generation standard. It
|
||||
has many extensions to <acronym>SQL92</acronym> such as an
|
||||
the <acronym>SQL</acronym> standard. It
|
||||
has many extensions to <acronym>SQL</acronym> such as an
|
||||
extensible type system,
|
||||
inheritance, functions and production rules. These are
|
||||
features carried over from the original
|
||||
@ -24,7 +24,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.16 2000/12/22 19:31:56 peter
|
||||
<xref linkend="MELT93" endterm="MELT93"> and
|
||||
<xref linkend="DATE97" endterm="DATE97">.
|
||||
You should be aware that some language features
|
||||
are extensions to the <acronym>ANSI</acronym> standard.
|
||||
are extensions to the standard.
|
||||
</para>
|
||||
|
||||
<sect1 id="query-psql">
|
||||
@ -34,14 +34,15 @@ $Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.16 2000/12/22 19:31:56 peter
|
||||
In the examples that follow, we assume that you have
|
||||
created the mydb database as described in the previous
|
||||
subsection and have started <application>psql</application>.
|
||||
Examples in this manual can also be found in
|
||||
<filename>/usr/local/pgsql/src/tutorial/</filename>. Refer to the
|
||||
Examples in this manual can also be found in source distribution
|
||||
in the directory <filename>src/tutorial/</filename>. Refer to the
|
||||
<filename>README</filename> file in that directory for how to use them. To
|
||||
start the tutorial, do the following:
|
||||
|
||||
<programlisting>
|
||||
% cd /usr/local/pgsql/src/tutorial
|
||||
% psql -s mydb
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>cd <replaceable>...</replaceable>/src/tutorial</userinput>
|
||||
<prompt>$</prompt> <userinput>psql -s mydb</userinput>
|
||||
<computeroutput>
|
||||
Welcome to the POSTGRESQL interactive sql monitor:
|
||||
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
|
||||
|
||||
@ -49,9 +50,10 @@ Welcome to the POSTGRESQL interactive sql monitor:
|
||||
type \q to quit
|
||||
type \g or terminate with semicolon to execute query
|
||||
You are currently connected to the database: postgres
|
||||
</computeroutput>
|
||||
|
||||
mydb=> \i basics.sql
|
||||
</programlisting>
|
||||
<prompt>mydb=></prompt> <userinput>\i basics.sql</userinput>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -73,34 +75,33 @@ mydb=> \i basics.sql
|
||||
<title>Concepts</title>
|
||||
|
||||
<para>
|
||||
The fundamental notion in <productname>Postgres</productname> is that of a class,
|
||||
which is a named collection of object instances. Each
|
||||
instance has the same collection of named attributes,
|
||||
and each attribute is of a specific type. Furthermore,
|
||||
each instance has a permanent <firstterm>object identifier</firstterm>
|
||||
(<acronym>OID</acronym>)
|
||||
that is unique throughout the installation. Because
|
||||
<acronym>SQL</acronym> syntax refers to tables, we will use the terms
|
||||
<firstterm>table</firstterm> and <firstterm>class</firstterm> interchangeably.
|
||||
Likewise, an <acronym>SQL</acronym> <firstterm>row</firstterm> is an
|
||||
<firstterm>instance</firstterm> and <acronym>SQL</acronym>
|
||||
<firstterm>columns</firstterm>
|
||||
are <firstterm>attributes</firstterm>.
|
||||
As previously discussed, classes are grouped into
|
||||
databases, and a collection of databases managed by a
|
||||
single <application>postmaster</application> process constitutes a
|
||||
database cluster.
|
||||
The fundamental notion in <productname>Postgres</productname> is
|
||||
that of a <firstterm>table</firstterm>, which is a named
|
||||
collection of <firstterm>rows</firstterm>. Each row has the same
|
||||
set of named <firstterm>columns</firstterm>, and each column is of
|
||||
a specific type. Furthermore, each row has a permanent
|
||||
<firstterm>object identifier</firstterm> (<acronym>OID</acronym>)
|
||||
that is unique throughout the database cluster. Historially,
|
||||
tables have been called classes in
|
||||
<productname>Postgres</productname>, rows are object instances,
|
||||
and columns are attributes. This makes sense if you consider the
|
||||
object-relational aspects of the database system, but in this
|
||||
manual we will use the customary <acronym>SQL</acronym>
|
||||
terminology. As previously discussed,
|
||||
tables are grouped into databases, and a collection of databases
|
||||
managed by a single <application>postmaster</application> process
|
||||
constitutes a database cluster.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="query-table">
|
||||
<title>Creating a New Class</title>
|
||||
<title>Creating a New Table</title>
|
||||
|
||||
<para>
|
||||
You can create a new class by specifying the class
|
||||
name, along with all attribute names and their types:
|
||||
You can create a new table by specifying the table
|
||||
name, along with all column names and their types:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
CREATE TABLE weather (
|
||||
city varchar(80),
|
||||
temp_lo int, -- low temperature
|
||||
@ -108,7 +109,7 @@ CREATE TABLE weather (
|
||||
prcp real, -- precipitation
|
||||
date date
|
||||
);
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -135,22 +136,21 @@ CREATE TABLE weather (
|
||||
looks exactly like
|
||||
the command used to create a table in a traditional
|
||||
relational system. However, we will presently see that
|
||||
classes have properties that are extensions of the
|
||||
tables have properties that are extensions of the
|
||||
relational model.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="query-populate">
|
||||
<title>Populating a Class with Instances</title>
|
||||
<title>Populating a Table with Rows</title>
|
||||
|
||||
<para>
|
||||
The <command>INSERT</command> statement is used to populate a class with
|
||||
instances:
|
||||
The <command>INSERT</command> statement is used to populate a table with
|
||||
rows:
|
||||
|
||||
<programlisting>
|
||||
INSERT INTO weather
|
||||
VALUES ('San Francisco', 46, 50, 0.25, '11/27/1994');
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
INSERT INTO weather VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -160,10 +160,9 @@ INSERT INTO weather
|
||||
single atomic
|
||||
transaction directly to or from the target table. An example would be:
|
||||
|
||||
<programlisting>
|
||||
COPY weather FROM '/home/user/weather.txt'
|
||||
USING DELIMITERS '|';
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
COPY weather FROM '/home/user/weather.txt' USING DELIMITERS '|';
|
||||
</programlisting>
|
||||
|
||||
where the path name for the source file must be available to the
|
||||
backend server
|
||||
@ -172,38 +171,38 @@ COPY weather FROM '/home/user/weather.txt'
|
||||
</sect1>
|
||||
|
||||
<sect1 id="query-query">
|
||||
<title>Querying a Class</title>
|
||||
<title>Querying a Table</title>
|
||||
|
||||
<para>
|
||||
The weather class can be queried with normal relational
|
||||
The <classname>weather</classname> table can be queried with normal relational
|
||||
selection and projection queries. A <acronym>SQL</acronym>
|
||||
<command>SELECT</command>
|
||||
statement is used to do this. The statement is divided into
|
||||
a target list (the part that lists the attributes to be
|
||||
a target list (the part that lists the columns to be
|
||||
returned) and a qualification (the part that specifies
|
||||
any restrictions). For example, to retrieve all the
|
||||
rows of weather, type:
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
SELECT * FROM weather;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
and the output should be:
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
+--------------+---------+---------+------+------------+
|
||||
|city | temp_lo | temp_hi | prcp | date |
|
||||
+--------------+---------+---------+------+------------+
|
||||
|San Francisco | 46 | 50 | 0.25 | 11-27-1994 |
|
||||
|San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
|
||||
+--------------+---------+---------+------+------------+
|
||||
|San Francisco | 43 | 57 | 0 | 11-29-1994 |
|
||||
|San Francisco | 43 | 57 | 0 | 1994-11-29 |
|
||||
+--------------+---------+---------+------+------------+
|
||||
|Hayward | 37 | 54 | | 11-29-1994 |
|
||||
|Hayward | 37 | 54 | | 1994-11-29 |
|
||||
+--------------+---------+---------+------+------------+
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
You may specify any arbitrary expressions in the target list. For
|
||||
example, you can do:
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -212,31 +211,31 @@ SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
|
||||
<command>NOT</command>) are
|
||||
allowed in the qualification of any query. For example,
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
SELECT * FROM weather
|
||||
WHERE city = 'San Francisco'
|
||||
AND prcp > 0.0;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
results in:
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
+--------------+---------+---------+------+------------+
|
||||
|city | temp_lo | temp_hi | prcp | date |
|
||||
+--------------+---------+---------+------+------------+
|
||||
|San Francisco | 46 | 50 | 0.25 | 11-27-1994 |
|
||||
|San Francisco | 46 | 50 | 0.25 | 1994-11-27 |
|
||||
+--------------+---------+---------+------+------------+
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As a final note, you can specify that the results of a
|
||||
select can be returned in a <firstterm>sorted order</firstterm>
|
||||
or with <firstterm>duplicate instances</firstterm> removed.
|
||||
or with duplicate rows removed.
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
SELECT DISTINCT city
|
||||
FROM weather
|
||||
ORDER BY city;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -244,37 +243,37 @@ SELECT DISTINCT city
|
||||
<title>Redirecting SELECT Queries</title>
|
||||
|
||||
<para>
|
||||
Any <command>SELECT</command> query can be redirected to a new class
|
||||
<programlisting>
|
||||
Any <command>SELECT</command> query can be redirected to a new table
|
||||
<programlisting>
|
||||
SELECT * INTO TABLE temp FROM weather;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This forms an implicit <command>CREATE</command> command, creating a new
|
||||
class temp with the attribute names and types specified
|
||||
table temp with the column names and types specified
|
||||
in the target list of the <command>SELECT INTO</command> command. We can
|
||||
then, of course, perform any operations on the resulting
|
||||
class that we can perform on other classes.
|
||||
table that we can perform on other tables.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="query-join">
|
||||
<title>Joins Between Classes</title>
|
||||
<title>Joins Between Tables</title>
|
||||
|
||||
<para>
|
||||
Thus far, our queries have only accessed one class at a
|
||||
time. Queries can access multiple classes at once, or
|
||||
access the same class in such a way that multiple
|
||||
instances of the class are being processed at the same
|
||||
time. A query that accesses multiple instances of the
|
||||
same or different classes at one time is called a join
|
||||
Thus far, our queries have only accessed one table at a
|
||||
time. Queries can access multiple tables at once, or
|
||||
access the same table in such a way that multiple
|
||||
rows of the table are being processed at the same
|
||||
time. A query that accesses multiple rows of the
|
||||
same or different tables at one time is called a join
|
||||
query.
|
||||
As an example, say we wish to find all the records that
|
||||
are in the temperature range of other records. In
|
||||
effect, we need to compare the temp_lo and temp_hi
|
||||
attributes of each WEATHER instance to the temp_lo and
|
||||
temp_hi attributes of all other WEATHER instances.
|
||||
columns of each WEATHER row to the temp_lo and
|
||||
temp_hi columns of all other WEATHER columns.
|
||||
<note>
|
||||
<para>
|
||||
This is only a conceptual model. The actual join may
|
||||
@ -285,7 +284,7 @@ SELECT * INTO TABLE temp FROM weather;
|
||||
|
||||
We can do this with the following query:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high,
|
||||
W2.city, W2.temp_lo AS low, W2.temp_hi AS high
|
||||
FROM weather W1, weather W2
|
||||
@ -299,14 +298,14 @@ SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high,
|
||||
+--------------+-----+------+---------------+-----+------+
|
||||
|San Francisco | 37 | 54 | San Francisco | 46 | 50 |
|
||||
+--------------+-----+------+---------------+-----+------+
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The semantics of such a join are
|
||||
that the qualification
|
||||
is a truth expression defined for the Cartesian product of
|
||||
the classes indicated in the query. For those instances in
|
||||
the tables indicated in the query. For those rows in
|
||||
the Cartesian product for which the qualification is true,
|
||||
<productname>Postgres</productname> computes and returns the
|
||||
values specified in the target list.
|
||||
@ -324,13 +323,13 @@ SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high,
|
||||
|
||||
<para>
|
||||
In this case, both <literal>W1</literal> and
|
||||
<literal>W2</literal> are surrogates for an
|
||||
instance of the class weather, and both range over all
|
||||
instances of the class. (In the terminology of most
|
||||
<literal>W2</literal> are surrogates for a
|
||||
row of the table weather, and both range over all
|
||||
rows of the table. (In the terminology of most
|
||||
database systems, <literal>W1</literal> and <literal>W2</literal>
|
||||
are known as <firstterm>range variables</firstterm>.)
|
||||
A query can contain an arbitrary number of
|
||||
class names and surrogates.
|
||||
table names and surrogates.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -338,17 +337,17 @@ SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high,
|
||||
<title>Updates</title>
|
||||
|
||||
<para>
|
||||
You can update existing instances using the
|
||||
You can update existing rows using the
|
||||
<command>UPDATE</command> command.
|
||||
Suppose you discover the temperature readings are
|
||||
all off by 2 degrees as of Nov 28, you may update the
|
||||
data as follow:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
UPDATE weather
|
||||
SET temp_hi = temp_hi - 2, temp_lo = temp_lo - 2
|
||||
WHERE date > '11/28/1994';
|
||||
</programlisting>
|
||||
WHERE date > '1994-11-28';
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -357,18 +356,18 @@ UPDATE weather
|
||||
|
||||
<para>
|
||||
Deletions are performed using the <command>DELETE</command> command:
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
DELETE FROM weather WHERE city = 'Hayward';
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
All weather recording belongs to Hayward is removed.
|
||||
All weather recording belonging to Hayward are removed.
|
||||
One should be wary of queries of the form
|
||||
<programlisting>
|
||||
DELETE FROM classname;
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
DELETE FROM <replaceable>tablename</replaceable>;
|
||||
</programlisting>
|
||||
|
||||
Without a qualification, <command>DELETE</command> will simply
|
||||
remove all instances of the given class, leaving it
|
||||
remove all rows from the given table, leaving it
|
||||
empty. The system will not request confirmation before
|
||||
doing this.
|
||||
</para>
|
||||
@ -385,7 +384,7 @@ DELETE FROM classname;
|
||||
For example, there are aggregates to compute the
|
||||
<function>count</function>, <function>sum</function>,
|
||||
<function>avg</function> (average), <function>max</function> (maximum) and
|
||||
<function>min</function> (minimum) over a set of instances.
|
||||
<function>min</function> (minimum) over a set of rows.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.18 2001/01/05 06:34:16 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.19 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -209,7 +209,7 @@ ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You must own the class in order to change its schema.
|
||||
You must own the table in order to change it.
|
||||
Renaming any part of the schema of a system
|
||||
catalog is not permitted.
|
||||
The <citetitle>PostgreSQL User's Guide</citetitle> has further
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/cluster.sgml,v 1.9 2000/07/22 04:30:26 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/cluster.sgml,v 1.10 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -23,7 +23,7 @@ Postgres documentation
|
||||
<date>1999-07-20</date>
|
||||
</refsynopsisdivinfo>
|
||||
<synopsis>
|
||||
CLUSTER <replaceable class="PARAMETER">indexname</replaceable> ON <replaceable class="PARAMETER">table</replaceable>
|
||||
CLUSTER <replaceable class="PARAMETER">indexname</replaceable> ON <replaceable class="PARAMETER">tablename</replaceable>
|
||||
</synopsis>
|
||||
|
||||
<refsect2 id="R2-SQL-CLUSTER-1">
|
||||
@ -115,18 +115,18 @@ ERROR: Relation <replaceable class="PARAMETER">table</replaceable> does not exis
|
||||
</title>
|
||||
<para>
|
||||
<command>CLUSTER</command> instructs <productname>Postgres</productname>
|
||||
to cluster the class specified
|
||||
to cluster the table specified
|
||||
by <replaceable class="parameter">table</replaceable> approximately
|
||||
based on the index specified by
|
||||
<replaceable class="parameter">indexname</replaceable>. The index must
|
||||
already have been defined on
|
||||
<replaceable class="parameter">classname</replaceable>.
|
||||
<replaceable class="parameter">tablename</replaceable>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When a class is clustered, it is physically reordered
|
||||
When a table is clustered, it is physically reordered
|
||||
based on the index information. The clustering is static.
|
||||
In other words, as the class is updated, the changes are
|
||||
In other words, as the table is updated, the changes are
|
||||
not clustered. No attempt is made to keep new instances or
|
||||
updated tuples clustered. If one wishes, one can
|
||||
re-cluster manually by issuing the command again.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.19 2001/01/03 20:04:09 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.20 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -590,9 +590,9 @@ ZW ZIMBABWE
|
||||
The following is the same data, output in binary format on a Linux/i586
|
||||
machine. The data is shown after filtering through
|
||||
the Unix utility <command>od -c</command>. The table has
|
||||
three fields; the first is <classname>char(2)</classname>,
|
||||
the second is <classname>text</classname>, and the third is
|
||||
<classname>int4</classname>. All the
|
||||
three fields; the first is <type>char(2)</type>,
|
||||
the second is <type>text</type>, and the third is
|
||||
<type>integer</type>. All the
|
||||
rows have a null value in the third field.
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.17 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.18 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -208,7 +208,7 @@ ERROR: Cannot create index: 'index_name' already exists.
|
||||
In the second syntax shown above, an index is defined
|
||||
on the result of a user-specified function
|
||||
<replaceable class="parameter">func_name</replaceable> applied
|
||||
to one or more attributes of a single class.
|
||||
to one or more columns of a single table.
|
||||
These <firstterm>functional indices</firstterm>
|
||||
can be used to obtain fast access to data
|
||||
based on operators that would normally require some
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.17 2000/10/10 04:42:43 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.18 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -350,7 +350,7 @@ MYBOXES.description <<< box '((0,0), (1,1))'
|
||||
instance variables, the query optimizer must estimate the
|
||||
size of the resulting join. The function join_proc will
|
||||
return another floating point number which will be multiplied
|
||||
by the cardinalities of the two classes involved to
|
||||
by the cardinalities of the two tables involved to
|
||||
compute the expected result size.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.21 2001/01/06 04:14:35 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.22 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -213,7 +213,7 @@ CREATE
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You must have rule definition access to a class in order
|
||||
You must have rule definition access to a table in order
|
||||
to define a rule on it. Use <command>GRANT</command>
|
||||
and <command>REVOKE</command> to change permissions.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.15 2000/10/05 19:48:18 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.16 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -336,7 +336,7 @@ CREATE
|
||||
<title>Examples</title>
|
||||
<para>
|
||||
This command creates the box data type and then uses the
|
||||
type in a class definition:
|
||||
type in a table definition:
|
||||
<programlisting>
|
||||
CREATE TYPE box (INTERNALLENGTH = 8,
|
||||
INPUT = my_procedure_1, OUTPUT = my_procedure_2);
|
||||
@ -357,7 +357,7 @@ CREATE TABLE myarrays (id int4, numbers int4array);
|
||||
|
||||
<para>
|
||||
This command creates a large object type and uses it in
|
||||
a class definition:
|
||||
a table definition:
|
||||
|
||||
<programlisting>
|
||||
CREATE TYPE bigobj (INPUT = lo_filein, OUTPUT = lo_fileout,
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.9 2000/03/27 17:14:42 thomas Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.10 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -123,8 +123,8 @@ CREATE VIEW vista AS SELECT text 'Hello World'
|
||||
Description
|
||||
</title>
|
||||
<para>
|
||||
<command>CREATE VIEW</command> will define a view of a table or
|
||||
class. This view is not physically materialized. Specifically, a query
|
||||
<command>CREATE VIEW</command> will define a view of a table.
|
||||
This view is not physically materialized. Specifically, a query
|
||||
rewrite retrieve rule is automatically generated to support
|
||||
retrieve operations on views.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createuser.sgml,v 1.15 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createuser.sgml,v 1.16 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -196,7 +196,7 @@ Postgres documentation
|
||||
<application>createuser</application> creates a
|
||||
new <productname>Postgres</productname> user.
|
||||
Only users with <literal>usesuper</literal> set in
|
||||
the <literal>pg_shadow</literal> class can create
|
||||
the <literal>pg_shadow</literal> table can create
|
||||
new <productname>Postgres</productname> users.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/delete.sgml,v 1.11 2000/06/09 01:44:00 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/delete.sgml,v 1.12 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -120,7 +120,7 @@ DELETE <replaceable class="parameter">count</replaceable>
|
||||
|
||||
<para>
|
||||
By default DELETE will delete tuples in the table specified
|
||||
and all its sub-classes. If you wish to only update the
|
||||
and all its sub-tables. If you wish to only update the
|
||||
specific table mentioned, you should use the ONLY clause.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_type.sgml,v 1.8 2000/10/22 23:32:38 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_type.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -113,7 +113,7 @@ ERROR: RemoveType: type '<replaceable class="parameter">typename</replaceable>'
|
||||
</para>
|
||||
<para>
|
||||
It is the user's responsibility to remove any operators,
|
||||
functions, aggregates, access methods, subtypes, and classes
|
||||
functions, aggregates, access methods, subtypes, and tables
|
||||
that use a deleted type.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropuser.sgml,v 1.10 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropuser.sgml,v 1.11 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -148,7 +148,7 @@ Postgres documentation
|
||||
<productname>Postgres</productname> user
|
||||
<emphasis>and</emphasis> the databases which that user owned.
|
||||
Only users with <literal>usesuper</literal> set in
|
||||
the <literal>pg_shadow</literal> class can destroy
|
||||
the <literal>pg_shadow</literal> table can destroy
|
||||
<productname>Postgres</productname> users.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/insert.sgml,v 1.12 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/insert.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -129,7 +129,7 @@ INSERT 0 <replaceable>#</replaceable>
|
||||
|
||||
<para>
|
||||
<command>INSERT</command> allows one to insert new rows into a
|
||||
class or table. One can insert
|
||||
table. One can insert
|
||||
a single row at a time or several rows as a result of a query.
|
||||
The columns in the target list may be listed in any order.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.36 2001/01/08 21:30:37 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.37 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -31,7 +31,7 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replac
|
||||
[ HAVING <replaceable class="PARAMETER">condition</replaceable> [, ...] ]
|
||||
[ { UNION | INTERSECT | EXCEPT [ ALL ] } <replaceable class="PARAMETER">select</replaceable> ]
|
||||
[ ORDER BY <replaceable class="PARAMETER">expression</replaceable> [ ASC | DESC | USING <replaceable class="PARAMETER">operator</replaceable> ] [, ...] ]
|
||||
[ FOR UPDATE [ OF <replaceable class="PARAMETER">class_name</replaceable> [, ...] ] ]
|
||||
[ FOR UPDATE [ OF <replaceable class="PARAMETER">tablename</replaceable> [, ...] ] ]
|
||||
[ LIMIT { <replaceable class="PARAMETER">count</replaceable> | ALL } [ { OFFSET | , } <replaceable class="PARAMETER">start</replaceable> ]]
|
||||
|
||||
where <replaceable class="PARAMETER">from_item</replaceable> can be:
|
||||
@ -397,11 +397,11 @@ where <replaceable class="PARAMETER">from_item</replaceable> can be:
|
||||
|
||||
<para>
|
||||
When a FROM item is a simple table name, it implicitly includes rows
|
||||
from subclasses (inheritance children) of the table.
|
||||
from sub-tables (inheritance children) of the table.
|
||||
<command>ONLY</command> will
|
||||
suppress rows from subclasses of the table. Before
|
||||
suppress rows from sub-tables of the table. Before
|
||||
<Productname>Postgres</Productname> 7.1,
|
||||
this was the default result, and adding subclasses was done
|
||||
this was the default result, and adding sub-tables was done
|
||||
by appending <command>*</command> to the table name.
|
||||
This old behaviour is available via the command
|
||||
<command>SET SQL_Inheritance TO OFF;</command>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select_into.sgml,v 1.8 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select_into.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -31,7 +31,7 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replac
|
||||
[ HAVING <replaceable class="PARAMETER">condition</replaceable> [, ...] ]
|
||||
[ { UNION | INTERSECT | EXCEPT [ ALL ] } <replaceable class="PARAMETER">select</replaceable> ]
|
||||
[ ORDER BY <replaceable class="PARAMETER">expression</replaceable> [ ASC | DESC | USING <replaceable class="PARAMETER">operator</replaceable> ] [, ...] ]
|
||||
[ FOR UPDATE [ OF <replaceable class="PARAMETER">class_name</replaceable> [, ...] ] ]
|
||||
[ FOR UPDATE [ OF <replaceable class="PARAMETER">tablename</replaceable> [, ...] ] ]
|
||||
[ LIMIT { <replaceable class="PARAMETER">count</replaceable> | ALL } [ { OFFSET | , } <replaceable class="PARAMETER">start</replaceable> ]]
|
||||
|
||||
where <replaceable class="PARAMETER">from_item</replaceable> can be:
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/unlisten.sgml,v 1.13 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/unlisten.sgml,v 1.14 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -114,7 +114,7 @@ UNLISTEN { <replaceable class="PARAMETER">notifyname</replaceable> | * }
|
||||
Notes
|
||||
</title>
|
||||
<para>
|
||||
<replaceable class="PARAMETER">classname</replaceable>
|
||||
<replaceable class="PARAMETER">notifyname</replaceable>
|
||||
need not be a valid class name but can be any string valid
|
||||
as a name up to 32 characters long.
|
||||
</para>
|
||||
@ -124,13 +124,6 @@ UNLISTEN { <replaceable class="PARAMETER">notifyname</replaceable> | * }
|
||||
Each backend will automatically execute <command>UNLISTEN *</command> when
|
||||
exiting.
|
||||
</para>
|
||||
<para>
|
||||
A restriction in some previous releases of
|
||||
<productname>Postgres</productname> that a
|
||||
<replaceable class="PARAMETER">classname</replaceable>
|
||||
which does not correspond to an actual table must be enclosed in double-quotes
|
||||
is no longer present.
|
||||
</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v 1.13 2000/12/25 23:15:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v 1.14 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -143,7 +143,7 @@ UPDATE <replaceable class="parameter">#</replaceable>
|
||||
|
||||
<para>
|
||||
By default UPDATE will update tuples in the table specified
|
||||
and all its sub-classes. If you wish to only update the
|
||||
and all its sub-tables. If you wish to only update the
|
||||
specific table mentioned, you should use the ONLY clause.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.12 2000/10/05 19:57:23 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -150,10 +150,10 @@ NOTICE: Index <replaceable class="PARAMETER">index</replaceable>: Pages 28;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<command>VACUUM</command> opens every class in the database,
|
||||
<command>VACUUM</command> opens every table in the database,
|
||||
cleans out records from rolled back transactions, and updates statistics in the
|
||||
system catalogs. The statistics maintained include the number of
|
||||
tuples and number of pages stored in all classes.
|
||||
tuples and number of pages stored in all tables.
|
||||
</para>
|
||||
|
||||
|
||||
@ -181,7 +181,7 @@ NOTICE: Index <replaceable class="PARAMETER">index</replaceable>: Pages 28;
|
||||
<para>
|
||||
We recommend that active production databases be
|
||||
<command>VACUUM</command>-ed nightly, in order to remove
|
||||
expired rows. After copying a large class into
|
||||
expired rows. After copying a large table into
|
||||
<productname>Postgres</productname> or after deleting a large number
|
||||
of records, it may be a good idea to issue a <command>VACUUM
|
||||
ANALYZE</command> query. This will update the system catalogs with
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.34 2001/01/13 18:34:51 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.35 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -553,15 +553,12 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
|
||||
|
||||
<sect1 id="sql-syntax-columns">
|
||||
<title>Fields and Columns</title>
|
||||
|
||||
<sect2>
|
||||
<title>Fields</title>
|
||||
<title>Columns</title>
|
||||
|
||||
<para>
|
||||
A <firstterm>field</firstterm>
|
||||
is either a user-defined attribute of a given class or one of the
|
||||
following system-defined attributes:
|
||||
A <firstterm>column</firstterm>
|
||||
is either a user-defined column of a given table or one of the
|
||||
following system-defined columns:
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -653,40 +650,29 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
<xref linkend="STON87a" endterm="STON87a">.
|
||||
Transaction and command identifiers are 32 bit quantities.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Columns</title>
|
||||
|
||||
<para>
|
||||
A <firstterm>column</firstterm> is a construct of the form:
|
||||
A column can be referenced in the form:
|
||||
|
||||
<synopsis>
|
||||
<replaceable>instance</replaceable>{.<replaceable>composite_field</replaceable>}.<replaceable>field</replaceable> `['<replaceable>subscript</replaceable>`]'
|
||||
</synopsis>
|
||||
<synopsis>
|
||||
<replaceable>corelation</replaceable>.<replaceable>columnname</replaceable> `['<replaceable>subscript</replaceable>`]'
|
||||
</synopsis>
|
||||
|
||||
<replaceable>instance</replaceable>
|
||||
identifies a particular class and can be thought of as standing for
|
||||
the instances of that class. An instance variable is either a class
|
||||
name, an alias for a class defined by means of a FROM clause,
|
||||
or the keyword NEW or OLD.
|
||||
(NEW and OLD can only appear in the action portion of a rule, while
|
||||
other instance variables can be used in any SQL statement.) The
|
||||
instance name can be omitted if the first field name is unique
|
||||
across all the classes being used in the current query.
|
||||
<replaceable>composite_field</replaceable>
|
||||
is a field of of one of the Postgres composite types,
|
||||
while successive composite fields select attributes in the
|
||||
class(s) to which the composite field evaluates. Lastly,
|
||||
<replaceable>field</replaceable>
|
||||
is a normal (base type) field in the class(s) last addressed. If
|
||||
<replaceable>field</replaceable>
|
||||
is of an array type,
|
||||
then the optional <replaceable>subscript</replaceable>
|
||||
selects a specific element in the array. If no subscript is
|
||||
provided, then the whole array is selected.
|
||||
<replaceable>corelation</replaceable> is either the name of a
|
||||
table, an alias for a table defined by means of a FROM clause, or
|
||||
the keyword <literal>NEW</literal> or <literal>OLD</literal>.
|
||||
(NEW and OLD can only appear in the action portion of a rule,
|
||||
while other corelation names can be used in any SQL statement.)
|
||||
The corelation name can be omitted if the column name is unique
|
||||
across all the tables being used in the current query. If
|
||||
<replaceable>column</replaceable> is of an array type, then the
|
||||
optional <replaceable>subscript</replaceable> selects a specific
|
||||
element in the array. If no subscript is provided, then the
|
||||
whole array is selected. Refer to the description of the
|
||||
particular commands in the <citetitle>PostgreSQL Reference
|
||||
Manual</citetitle> for the allowed syntax in each case.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sql-expressions">
|
||||
@ -861,10 +847,10 @@ sqrt(emp.salary)
|
||||
The simplest possibility for a from-expression is:
|
||||
|
||||
<synopsis>
|
||||
<replaceable>class_reference</replaceable> [ [ AS ] <replaceable class="PARAMETER">alias</replaceable> ]
|
||||
<replaceable>table_reference</replaceable> [ [ AS ] <replaceable class="PARAMETER">alias</replaceable> ]
|
||||
</synopsis>
|
||||
|
||||
where <replaceable>class_reference</replaceable> is of the form
|
||||
where <replaceable>table_reference</replaceable> is of the form
|
||||
|
||||
<synopsis>
|
||||
[ ONLY ] <replaceable class="PARAMETER">table_name</replaceable> [ * ]
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.11 2000/11/24 17:44:22 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.12 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<book id="tutorial">
|
||||
@ -33,7 +33,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/tutorial.sgml,v 1.11 2000/11/24 17:44
|
||||
developed originally in the UC Berkeley Computer Science Department,
|
||||
pioneered many of the object-relational concepts
|
||||
now becoming available in some commercial databases.
|
||||
It provides SQL92/SQL3 language support,
|
||||
It provides SQL92/SQL99 language support,
|
||||
transaction integrity, and type extensibility.
|
||||
<productname>PostgreSQL</productname> is an open-source descendant
|
||||
of this original Berkeley code.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.23 2001/01/06 11:58:56 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.24 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<book id="user">
|
||||
@ -35,7 +35,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.23 2001/01/06 11:58:56
|
||||
developed originally in the UC Berkeley Computer Science Department,
|
||||
pioneered many of the object-relational concepts
|
||||
now becoming available in some commercial databases.
|
||||
It provides SQL92/SQL3 language support,
|
||||
It provides SQL92/SQL99 language support,
|
||||
transaction integrity, and type extensibility.
|
||||
<productname>PostgreSQL</productname> is an open-source descendant
|
||||
of this original Berkeley code.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.9 2000/10/23 00:46:06 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.10 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xaggr">
|
||||
@ -31,9 +31,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.9 2000/10/23 00:46:06 tgl Ex
|
||||
<para>
|
||||
If we define an aggregate that does not use a final function,
|
||||
we have an aggregate that computes a running function of
|
||||
the attribute values from each instance. "Sum" is an
|
||||
the column values from each row. "Sum" is an
|
||||
example of this kind of aggregate. "Sum" starts at
|
||||
zero and always adds the current instance's value to
|
||||
zero and always adds the current row's value to
|
||||
its running total. For example, if we want to make a Sum
|
||||
aggregate to work on a datatype for complex numbers,
|
||||
we only need the addition function for that datatype.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.27 2001/01/12 22:15:32 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.28 2001/01/13 23:58:55 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xfunc">
|
||||
@ -202,7 +202,7 @@ SELECT name, double_salary(EMP) AS dream
|
||||
return composite types, we must first introduce the
|
||||
function notation for projecting attributes. The simple way
|
||||
to explain this is that we can usually use the
|
||||
notations attribute(class) and class.attribute interchangably:
|
||||
notations attribute(table) and table.attribute interchangably:
|
||||
|
||||
<programlisting>
|
||||
--
|
||||
@ -223,10 +223,10 @@ SELECT name(EMP) AS youngster
|
||||
<para>
|
||||
As we shall see, however, this is not always the case.
|
||||
This function notation is important when we want to use
|
||||
a function that returns a single instance. We do this
|
||||
by assembling the entire instance within the function,
|
||||
a function that returns a single row. We do this
|
||||
by assembling the entire row within the function,
|
||||
attribute by attribute. This is an example of a function
|
||||
that returns a single EMP instance:
|
||||
that returns a single EMP row:
|
||||
|
||||
<programlisting>
|
||||
CREATE FUNCTION new_emp()
|
||||
@ -266,10 +266,10 @@ ERROR: function declared to return emp returns varchar instead of text at colum
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
When calling a function that returns an instance, we
|
||||
cannot retrieve the entire instance. We must either
|
||||
project an attribute out of the instance or pass the
|
||||
entire instance into another function.
|
||||
When calling a function that returns a row, we
|
||||
cannot retrieve the entire row. We must either
|
||||
project an attribute out of the row or pass the
|
||||
entire row into another function.
|
||||
|
||||
<programlisting>
|
||||
SELECT name(new_emp()) AS nobody;
|
||||
@ -1012,7 +1012,7 @@ concat_text(PG_FUNCTION_ARGS)
|
||||
Therefore, <productname>Postgres</productname> provides
|
||||
a procedural interface for accessing fields of composite types
|
||||
from C. As <productname>Postgres</productname> processes
|
||||
a set of instances, each instance will be passed into your
|
||||
a set of rows, each row will be passed into your
|
||||
function as an opaque structure of type <literal>TUPLE</literal>.
|
||||
Suppose we want to write a function to answer the query
|
||||
|
||||
@ -1029,7 +1029,7 @@ WHERE name = 'Bill' OR name = 'Sam';
|
||||
#include "executor/executor.h" /* for GetAttributeByName() */
|
||||
|
||||
bool
|
||||
c_overpaid(TupleTableSlot *t, /* the current instance of EMP */
|
||||
c_overpaid(TupleTableSlot *t, /* the current row of EMP */
|
||||
int32 limit)
|
||||
{
|
||||
bool isnull;
|
||||
@ -1066,7 +1066,7 @@ c_overpaid(PG_FUNCTION_ARGS)
|
||||
<para>
|
||||
<function>GetAttributeByName</function> is the
|
||||
<productname>Postgres</productname> system function that
|
||||
returns attributes out of the current instance. It has
|
||||
returns attributes out of the current row. It has
|
||||
three arguments: the argument of type <type>TupleTableSlot*</type> passed into
|
||||
the function, the name of the desired attribute, and a
|
||||
return parameter that tells whether the attribute
|
||||
@ -1088,8 +1088,8 @@ LANGUAGE 'c';
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While there are ways to construct new instances or modify
|
||||
existing instances from within a C function, these
|
||||
While there are ways to construct new rows or modify
|
||||
existing rows from within a C function, these
|
||||
are far too complex to discuss in this manual.
|
||||
</para>
|
||||
</sect2>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.12 2000/12/26 00:10:37 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -27,7 +27,7 @@ Postgres documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>pg_am</filename> class contains one instance for every user
|
||||
The <filename>pg_am</filename> table contains one row for every user
|
||||
defined access method. Support for the heap access method is built into
|
||||
<productname>Postgres</productname>, but every other access method is
|
||||
described here. The schema is
|
||||
@ -38,7 +38,7 @@ Postgres documentation
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Attribute</entry>
|
||||
<entry>Column</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
@ -49,7 +49,7 @@ Postgres documentation
|
||||
</row>
|
||||
<row>
|
||||
<entry>amowner</entry>
|
||||
<entry>object id of the owner's instance in pg_user</entry>
|
||||
<entry>user id of the owner</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>amstrategies</entry>
|
||||
@ -74,7 +74,7 @@ Postgres documentation
|
||||
<entry>...</entry>
|
||||
<entry>procedure identifiers for interface routines to the access
|
||||
method. For example, regproc ids for opening, closing, and
|
||||
getting instances from the access method appear here.</entry>
|
||||
getting rows from the access method appear here.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -82,11 +82,11 @@ Postgres documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <acronym>object ID</acronym> of the instance in
|
||||
<filename>pg_am</filename> is used as a foreign key in lots of other
|
||||
classes. You don't need to add a new instance to this class; all
|
||||
you're interested in is the <acronym>object ID</acronym> of the access
|
||||
method instance you want to extend:
|
||||
The <acronym>object ID</acronym> of the row in
|
||||
<filename>pg_am</filename> is used as a foreign key in a lot of other
|
||||
tables. You do not need to add a new rows to this table; all that
|
||||
you are interested in is the <acronym>object ID</acronym> of the access
|
||||
method row you want to extend:
|
||||
|
||||
<programlisting>
|
||||
SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
@ -102,7 +102,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>amstrategies</filename> attribute exists to standardize
|
||||
The <filename>amstrategies</filename> column exists to standardize
|
||||
comparisons across data types. For example, <acronym>B-tree</acronym>s
|
||||
impose a strict ordering on keys, lesser to greater. Since
|
||||
<productname>Postgres</productname> allows the user to define operators,
|
||||
@ -125,7 +125,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
Defining a new set of strategies is beyond the scope of this discussion,
|
||||
but we'll explain how <acronym>B-tree</acronym> strategies work because
|
||||
you'll need to know that to add a new operator class. In the
|
||||
<filename>pg_am</filename> class, the amstrategies attribute is the
|
||||
<filename>pg_am</filename> table, the amstrategies column is the
|
||||
number of strategies defined for this access method. For
|
||||
<acronym>B-tree</acronym>s, this number is 5. These strategies
|
||||
correspond to
|
||||
@ -193,8 +193,8 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
<para>
|
||||
In order to manage diverse support routines consistently across all
|
||||
<productname>Postgres</productname> access methods,
|
||||
<filename>pg_am</filename> includes an attribute called
|
||||
<filename>amsupport</filename>. This attribute records the number of
|
||||
<filename>pg_am</filename> includes a column called
|
||||
<filename>amsupport</filename>. This column records the number of
|
||||
support routines used by an access method. For <acronym>B-tree</acronym>s,
|
||||
this number is one -- the routine to take two keys and return -1, 0, or
|
||||
+1, depending on whether the first key is less than, equal
|
||||
@ -228,14 +228,14 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The next class of interest is <filename>pg_opclass</filename>. This class
|
||||
The next table of interest is <filename>pg_opclass</filename>. This table
|
||||
exists only to associate an operator class name and perhaps a default type
|
||||
with an operator class oid. Some existing opclasses are <filename>int2_ops,
|
||||
int4_ops,</filename> and <filename>oid_ops</filename>. You need to add an
|
||||
instance with your opclass name (for example,
|
||||
int4_ops,</filename> and <filename>oid_ops</filename>. You need to add a
|
||||
row with your opclass name (for example,
|
||||
<filename>complex_abs_ops</filename>) to
|
||||
<filename>pg_opclass</filename>. The <filename>oid</filename> of
|
||||
this instance will be a foreign key in other classes, notably
|
||||
this row will be a foreign key in other tables, notably
|
||||
<filename>pg_amop</filename>.
|
||||
|
||||
<programlisting>
|
||||
@ -252,7 +252,7 @@ SELECT oid, opcname, opcdeftype
|
||||
(1 row)
|
||||
</programlisting>
|
||||
|
||||
Note that the oid for your <filename>pg_opclass</filename> instance will
|
||||
Note that the oid for your <filename>pg_opclass</filename> row will
|
||||
be different! Don't worry about this though. We'll get this number
|
||||
from the system later just like we got the oid of the type here.
|
||||
</para>
|
||||
@ -357,7 +357,7 @@ CREATE FUNCTION complex_abs_eq(complex, complex)
|
||||
hand, the support function returns whatever the particular access method
|
||||
expects -- in this case, a signed integer.) The final routine in the
|
||||
file is the "support routine" mentioned when we discussed the amsupport
|
||||
attribute of the <filename>pg_am</filename> class. We will use this
|
||||
column of the <filename>pg_am</filename> table. We will use this
|
||||
later on. For now, ignore it.
|
||||
</para>
|
||||
|
||||
@ -416,10 +416,10 @@ CREATE OPERATOR = (
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now we're ready to update <filename>pg_amop</filename> with our new
|
||||
Now we are ready to update <filename>pg_amop</filename> with our new
|
||||
operator class. The most important thing in this entire discussion
|
||||
is that the operators are ordered, from less than through greater
|
||||
than, in <filename>pg_amop</filename>. We add the instances we need:
|
||||
than, in <filename>pg_amop</filename>. We add the rows we need:
|
||||
|
||||
<programlisting>
|
||||
INSERT INTO pg_amop (amopid, amopclaid, amopopr, amopstrategy)
|
||||
@ -440,7 +440,7 @@ CREATE OPERATOR = (
|
||||
The next step is registration of the "support routine" previously
|
||||
described in our discussion of <filename>pg_am</filename>. The
|
||||
<filename>oid</filename> of this support routine is stored in the
|
||||
<filename>pg_amproc</filename> class, keyed by the access method
|
||||
<filename>pg_amproc</filename> table, keyed by the access method
|
||||
<filename>oid</filename> and the operator class <filename>oid</filename>.
|
||||
First, we need to register the function in
|
||||
<productname>Postgres</productname> (recall that we put the
|
||||
@ -463,7 +463,7 @@ CREATE OPERATOR = (
|
||||
</programlisting>
|
||||
|
||||
(Again, your <filename>oid</filename> number will probably be different.)
|
||||
We can add the new instance as follows:
|
||||
We can add the new row as follows:
|
||||
|
||||
<programlisting>
|
||||
INSERT INTO pg_amproc (amid, amopclaid, amproc, amprocnum)
|
||||
|
@ -3,7 +3,7 @@
|
||||
<para>
|
||||
As previously mentioned, there are two kinds of types
|
||||
in <productname>Postgres</productname>: base types (defined in a programming language)
|
||||
and composite types (instances).
|
||||
and composite types.
|
||||
Examples in this section up to interfacing indices can
|
||||
be found in <filename>complex.sql</filename> and <filename>complex.c</filename>. Composite examples
|
||||
are in <filename>funcs.sql</filename>.
|
||||
|
Loading…
Reference in New Issue
Block a user