mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-16 09:20:25 +02:00
14d330b5b6
flexible about the extension of the graphic files, allow for other formats in print output. (Generating these formats is not implemented yet.)
288 lines
9.6 KiB
Plaintext
288 lines
9.6 KiB
Plaintext
<!--
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.13 2001/09/30 16:05:54 petere Exp $
|
|
-->
|
|
|
|
<chapter id="extend">
|
|
<title>Extending <acronym>SQL</acronym>: An Overview</title>
|
|
|
|
<para>
|
|
In the sections that follow, we will discuss how you
|
|
can extend the <productname>Postgres</productname>
|
|
<acronym>SQL</acronym> query language by adding:
|
|
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
<listitem>
|
|
<para>
|
|
functions
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
types
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
operators
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
aggregates
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<sect1 id="extend-how">
|
|
<title>How Extensibility Works</title>
|
|
|
|
<para>
|
|
<productname>Postgres</productname> is extensible because its operation is
|
|
catalog-driven. If you are familiar with standard
|
|
relational systems, you know that they store information
|
|
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 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 tables can be modified by
|
|
the user, and since <productname>Postgres</productname> bases its internal operation
|
|
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
|
|
specially-written by the <acronym>DBMS</acronym> vendor.
|
|
</para>
|
|
|
|
<para>
|
|
<productname>Postgres</productname> is also unlike most other data managers in
|
|
that the server can incorporate user-written code into
|
|
itself through dynamic loading. That is, the user can
|
|
specify an object code file (e.g., a compiled .o file
|
|
or shared library) that implements a new type or function
|
|
and <productname>Postgres</productname> will load it as required. Code written
|
|
in <acronym>SQL</acronym> are even more trivial to add to the server.
|
|
This ability to modify its operation <quote>on the fly</quote> makes
|
|
<productname>Postgres</productname> uniquely suited for rapid prototyping of new
|
|
applications and storage structures.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="type-system">
|
|
<title>The <productname>Postgres</productname> Type System</title>
|
|
|
|
<para>
|
|
The <productname>Postgres</productname> type system
|
|
can be broken down in several ways.
|
|
Types are divided into base types and composite types.
|
|
Base types are those, like <firstterm>int4</firstterm>, that are implemented
|
|
in a language such as <productname>C</productname>. They generally correspond to
|
|
what are often known as <firstterm>abstract data types</firstterm>; <productname>Postgres</productname>
|
|
can only operate on such types through methods provided
|
|
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
|
|
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 rows of a table) but the
|
|
user can <quote>look inside</quote> at the attributes of these types
|
|
from the query language and optimize their retrieval by
|
|
(for example) defining indexes on the attributes.
|
|
<productname>Postgres</productname> base types are further
|
|
divided into built-in
|
|
types and user-defined types. Built-in types (like
|
|
<firstterm>int4</firstterm>) are those that are compiled
|
|
into the system.
|
|
User-defined types are those created by the user in the
|
|
manner to be described below.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="pg-system-catalogs">
|
|
<title>About the <productname>Postgres</productname> System Catalogs</title>
|
|
|
|
<para>
|
|
Having introduced the basic extensibility concepts, we
|
|
can now take a look at how the catalogs are actually
|
|
laid out. You can skip this section for now, but some
|
|
later sections will be incomprehensible without the
|
|
information given here, so mark this page for later
|
|
reference.
|
|
All system catalogs have names that begin with
|
|
<firstterm>pg_</firstterm>.
|
|
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.)
|
|
|
|
<table tocentry="1">
|
|
<title>Postgres System Catalogs</title>
|
|
<titleabbrev>Catalogs</titleabbrev>
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Catalog Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>pg_database</entry>
|
|
<entry> databases</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_class</entry>
|
|
<entry> tables</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_attribute</entry>
|
|
<entry> table columns</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_index</entry>
|
|
<entry> secondary indexes</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_proc</entry>
|
|
<entry> procedures (both C and SQL)</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_type</entry>
|
|
<entry> types (both base and complex)</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_operator</entry>
|
|
<entry> operators</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_aggregate</entry>
|
|
<entry> aggregates and aggregate functions</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_am</entry>
|
|
<entry> access methods</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_amop</entry>
|
|
<entry> access method operators</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_amproc</entry>
|
|
<entry> access method support functions</entry>
|
|
</row>
|
|
<row>
|
|
<entry>pg_opclass</entry>
|
|
<entry> access method operator classes</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</para>
|
|
|
|
<para>
|
|
<figure float="1" id="EXTEND-CATALOGS">
|
|
<title>The major <productname>Postgres</productname> system catalogs</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="catalogs" align="center">
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
The Reference Manual gives a more detailed explanation
|
|
of these catalogs and their columns. However,
|
|
<xref linkend="EXTEND-CATALOGS">
|
|
shows the major entities and their relationships
|
|
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
|
|
actually start looking at the contents of the catalogs
|
|
and see how they relate to each other. For now, the
|
|
main things to take away from this diagram are as follows:
|
|
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
<listitem>
|
|
<para>
|
|
In several of the sections that follow, we will
|
|
present various join queries on the system
|
|
catalogs that display information we need to extend
|
|
the system. Looking at this diagram should make
|
|
some of these join queries (which are often
|
|
three- or four-way joins) more understandable,
|
|
because you will be able to see that the
|
|
columns used in the queries form foreign keys
|
|
in other tables.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Types and procedures
|
|
are central to the schema.
|
|
|
|
<note>
|
|
<para>
|
|
We use the words <firstterm>procedure</firstterm>
|
|
and <firstterm>function</firstterm> more or less interchangeably.
|
|
</para>
|
|
</note>
|
|
|
|
Nearly every catalog contains some reference to
|
|
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 rows of other catalogs.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
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
|
|
pg_am, pg_amop, pg_amproc, pg_operator and
|
|
pg_opclass are particularly hard to understand
|
|
and will be described in depth (in the section
|
|
on interfacing types and operators to indexes)
|
|
after we have discussed basic extensions.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode:sgml
|
|
sgml-omittag:nil
|
|
sgml-shorttag:t
|
|
sgml-minimize-attributes:nil
|
|
sgml-always-quote-attributes:t
|
|
sgml-indent-step:1
|
|
sgml-indent-data:t
|
|
sgml-parent-document:nil
|
|
sgml-default-dtd-file:"./reference.ced"
|
|
sgml-exposed-tags:nil
|
|
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
-->
|