1
1
<!--
2
- $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thomas Exp $
2
+ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.15 2002/01/07 02:29:11 petere Exp $
3
3
-->
4
4
5
5
<chapter id="extend">
@@ -18,7 +18,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
18
18
</listitem>
19
19
<listitem>
20
20
<para>
21
- types
21
+ data types
22
22
</para>
23
23
</listitem>
24
24
<listitem>
@@ -56,17 +56,16 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
56
56
extended by users. By comparison, conventional
57
57
database systems can only be extended by changing hardcoded
58
58
procedures within the <acronym>DBMS</acronym> or by loading modules
59
- specially- written by the <acronym>DBMS</acronym> vendor.
59
+ specially written by the <acronym>DBMS</acronym> vendor.
60
60
</para>
61
61
62
62
<para>
63
63
<productname>PostgreSQL</productname> is also unlike most other data managers in
64
64
that the server can incorporate user-written code into
65
65
itself through dynamic loading. That is, the user can
66
- specify an object code file (e.g., a compiled .o file
67
- or shared library) that implements a new type or function
66
+ specify an object code file (e.g., a shared library) that implements a new type or function
68
67
and <productname>PostgreSQL</productname> will load it as required. Code written
69
- in <acronym>SQL</acronym> are even more trivial to add to the server.
68
+ in <acronym>SQL</acronym> is even more trivial to add to the server.
70
69
This ability to modify its operation <quote>on the fly</quote> makes
71
70
<productname>PostgreSQL</productname> uniquely suited for rapid prototyping of new
72
71
applications and storage structures.
@@ -80,14 +79,14 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
80
79
The <productname>PostgreSQL</productname> type system
81
80
can be broken down in several ways.
82
81
Types are divided into base types and composite types.
83
- Base types are those, like <firstterm >int4</firstterm >, that are implemented
84
- in a language such as <productname>C</productname> . They generally correspond to
82
+ Base types are those, like <type >int4</type >, that are implemented
83
+ in a language such as C . They generally correspond to
85
84
what are often known as <firstterm>abstract data types</firstterm>; <productname>PostgreSQL</productname>
86
85
can only operate on such types through methods provided
87
86
by the user and only understands the behavior of such
88
87
types to the extent that the user describes them.
89
88
Composite types are created whenever the user creates a
90
- table. EMP is an example of a composite type.
89
+ table.
91
90
</para>
92
91
93
92
<para>
@@ -100,10 +99,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
100
99
<productname>PostgreSQL</productname> base types are further
101
100
divided into built-in
102
101
types and user-defined types. Built-in types (like
103
- <firstterm >int4</firstterm >) are those that are compiled
102
+ <type >int4</type >) are those that are compiled
104
103
into the system.
105
104
User-defined types are those created by the user in the
106
- manner to be described below .
105
+ manner to be described later .
107
106
</para>
108
107
</sect1>
109
108
@@ -118,7 +117,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
118
117
information given here, so mark this page for later
119
118
reference.
120
119
All system catalogs have names that begin with
121
- <firstterm >pg_</firstterm >.
120
+ <literal >pg_</literal >.
122
121
The following tables contain information that may be
123
122
useful to the end user. (There are many other system
124
123
catalogs, but there should rarely be a reason to query
@@ -149,23 +148,23 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
149
148
</row>
150
149
<row>
151
150
<entry>pg_index</entry>
152
- <entry> secondary indexes</entry>
151
+ <entry> indexes</entry>
153
152
</row>
154
153
<row>
155
154
<entry>pg_proc</entry>
156
- <entry> procedures (both C and SQL) </entry>
155
+ <entry> procedures/functions </entry>
157
156
</row>
158
157
<row>
159
158
<entry>pg_type</entry>
160
- <entry> types (both base and complex)</entry>
159
+ <entry> data types (both base and complex)</entry>
161
160
</row>
162
161
<row>
163
162
<entry>pg_operator</entry>
164
163
<entry> operators</entry>
165
164
</row>
166
165
<row>
167
166
<entry>pg_aggregate</entry>
168
- <entry> aggregates and aggregate functions</entry>
167
+ <entry> aggregate functions</entry>
169
168
</row>
170
169
<row>
171
170
<entry>pg_am</entry>
@@ -198,7 +197,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
198
197
</mediaobject>
199
198
</figure>
200
199
201
- The Reference Manual gives a more detailed explanation
200
+ The <citetitle>Developer's Guide</citetitle> gives a more detailed explanation
202
201
of these catalogs and their columns. However,
203
202
<xref linkend="EXTEND-CATALOGS">
204
203
shows the major entities and their relationships
@@ -257,10 +256,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.14 2001/11/21 05:53:41 thom
257
256
have obvious meanings, but there are many
258
257
(particularly those that have to do with access
259
258
methods) that do not. The relationships between
260
- pg_am, pg_amop, pg_amproc, pg_operator and
261
- pg_opclass are particularly hard to understand
262
- and will be described in depth (in the section
263
- on interfacing types and operators to indexes)
259
+ <classname>pg_am</>, <classname>pg_amop</>, <classname>pg_amproc</>, <classname>pg_operator</>, and
260
+ <classname>pg_opclass</> are particularly hard to understand
261
+ and will be described in depth (in <xref linkend="xindex">)
264
262
after we have discussed basic extensions.
265
263
</para>
266
264
</listitem>
0 commit comments