aboutsummaryrefslogtreecommitdiff
path: root/doc/src/sgml/extend.sgml
blob: f9adeee281b9305bf713515e2acb00fcea3fb6db (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.22 2003/04/13 09:57:35 petere Exp $
-->

 <chapter id="extend">
  <title>Extending <acronym>SQL</acronym></title>

   <indexterm zone="extend">
    <primary>extending SQL</primary>
   </indexterm>

  <para>
   In  the  sections  that follow, we will discuss how you
   can extend the <productname>PostgreSQL</productname> 
   <acronym>SQL</acronym> query language by adding:

   <itemizedlist spacing="compact" mark="bullet">
    <listitem>
     <para>
      functions (starting in <xref linkend="xfunc">)
     </para>
    </listitem>
    <listitem>
     <para>
      data types (starting in <xref linkend="xtypes">)
     </para>
    </listitem>
    <listitem>
     <para>
      operators (starting in <xref linkend="xoper">)
     </para>
    </listitem>
    <listitem>
     <para>
      aggregates (starting in <xref linkend="xaggr">)
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <sect1 id="extend-how">
   <title>How Extensibility Works</title>

   <para>
    <productname>PostgreSQL</productname> is extensible because its operation  is  
    catalog-driven.   If  you  are familiar with standard 
    relational database 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>PostgreSQL</productname> and  standard  relational database systems  is
    that <productname>PostgreSQL</productname> stores much more information in its 
    catalogs: not only information about tables and  columns,
    but also information about data types, functions, access
    methods, and so on.  These tables can be  modified  by
    the  user, and since <productname>PostgreSQL</productname> bases its operation 
    on these tables, this means that <productname>PostgreSQL</productname> can  be
    extended   by   users.    By  comparison,  conventional
    database systems can only be extended by changing hardcoded  
    procedures in the source code or by loading modules
    specially written by the <acronym>DBMS</acronym> vendor.
   </para>

   <para>
    The PostgreSQL server can moreover incorporate user-written code into
    itself through dynamic loading.  That is, the user  can
    specify  an  object code file (e.g., a shared library) that implements a new type or  function,
    and <productname>PostgreSQL</productname> will load it as required.  Code written 
    in <acronym>SQL</acronym> is even more trivial to add to the  server.
    This ability to modify its operation <quote>on the fly</quote> makes
    <productname>PostgreSQL</productname> uniquely suited for rapid prototyping  of  new
    applications and storage structures.
   </para>
  </sect1>

  <sect1 id="type-system">
   <title>The <productname>PostgreSQL</productname> Type System</title>

   <indexterm zone="type-system">
    <primary>extending SQL</primary>
    <secondary>types</secondary>
   </indexterm>

   <indexterm zone="type-system">
    <primary>data types</primary>
   </indexterm>

   <para>
    Data types are divided into base types and composite  types.
    Base  types  are those, like <type>int4</type>, that are implemented
    in a language such as C.  They generally correspond  to
    what are often known as abstract data types.  <productname>PostgreSQL</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.  The
    user can <quote>look inside</quote> at the attributes of these types
    from the query language.
   </para>
  </sect1>

  &xfunc;
  &xtypes;
  &xoper;
  &xaggr;
  &xindex;

 </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:
-->