1
1
<!--
2
- $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.22 2003/04/13 09:57:35 petere Exp $
2
+ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.23 2003/08/09 22:50:21 tgl Exp $
3
3
-->
4
4
5
5
<chapter id="extend">
@@ -20,6 +20,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.22 2003/04/13 09:57:35 pete
20
20
functions (starting in <xref linkend="xfunc">)
21
21
</para>
22
22
</listitem>
23
+ <listitem>
24
+ <para>
25
+ aggregates (starting in <xref linkend="xaggr">)
26
+ </para>
27
+ </listitem>
23
28
<listitem>
24
29
<para>
25
30
data types (starting in <xref linkend="xtypes">)
@@ -32,7 +37,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.22 2003/04/13 09:57:35 pete
32
37
</listitem>
33
38
<listitem>
34
39
<para>
35
- aggregates (starting in <xref linkend="xaggr ">)
40
+ operator classes for indexes (starting in <xref linkend="xindex ">)
36
41
</para>
37
42
</listitem>
38
43
</itemizedlist>
@@ -47,7 +52,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.22 2003/04/13 09:57:35 pete
47
52
relational database systems, you know that they store information
48
53
about databases, tables, columns, etc., in what are
49
54
commonly known as system catalogs. (Some systems call
50
- this the data dictionary). The catalogs appear to the
55
+ this the data dictionary.) The catalogs appear to the
51
56
user as tables like any other, but the <acronym>DBMS</acronym> stores
52
57
its internal bookkeeping in them. One key difference
53
58
between <productname>PostgreSQL</productname> and standard relational database systems is
@@ -88,24 +93,113 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.22 2003/04/13 09:57:35 pete
88
93
</indexterm>
89
94
90
95
<para>
91
- Data types are divided into base types and composite types.
96
+ <productname>PostgreSQL</productname> data types are divided into base
97
+ types, composite types, domain types, and pseudo-types.
98
+ </para>
99
+
100
+ <para>
92
101
Base types are those, like <type>int4</type>, that are implemented
93
- in a language such as C. They generally correspond to
94
- what are often known as abstract data types. <productname>PostgreSQL</productname>
95
- can only operate on such types through methods provided
102
+ below the level of the <acronym>SQL</> language (typically in a low-level
103
+ language such as C). They generally correspond to
104
+ what are often known as abstract data types.
105
+ <productname>PostgreSQL</productname>
106
+ can only operate on such types through functions provided
96
107
by the user and only understands the behavior of such
97
- types to the extent that the user describes them.
98
- Composite types are created whenever the user creates a
99
- table. The
100
- user can <quote>look inside</quote> at the attributes of these types
101
- from the query language.
108
+ types to the extent that the user describes them. Base types are
109
+ further subdivided into scalar and array types. For each scalar type,
110
+ a corresponding array type is automatically created that can hold
111
+ variable-size arrays of that scalar type.
112
+ </para>
113
+
114
+ <para>
115
+ Composite types, or row types, are created whenever the user creates a
116
+ table; it's also possible to define a <quote>stand-alone</> composite
117
+ type with no associated table. A composite type is simply a list of
118
+ base types with associated field names. A value of a composite type
119
+ is a row or record of field values. The user can access the component
120
+ fields from <acronym>SQL</> queries.
121
+ </para>
122
+
123
+ <para>
124
+ A domain type is based on a particular base
125
+ type and for many purposes is interchangeable with its base type.
126
+ However, a domain may have constraints that restrict its valid values
127
+ to a subset of what the underlying base type would allow. Domains can
128
+ be created by simple <acronym>SQL</> commands.
102
129
</para>
130
+
131
+ <para>
132
+ Finally, there are a few <quote>pseudo-types</> for special purposes.
133
+ Pseudo-types cannot appear as fields of tables or composite types, but
134
+ they can be used to declare the argument and result types of functions.
135
+ This provides a mechanism within the type system to identify special
136
+ classes of functions. <xref
137
+ linkend="datatype-pseudotypes-table"> lists the existing
138
+ pseudo-types.
139
+ </para>
140
+
141
+ <sect2 id="types-polymorphic">
142
+ <title>Polymorphic Types and Functions</title>
143
+
144
+ <indexterm>
145
+ <primary>polymorphic types</primary>
146
+ </indexterm>
147
+
148
+ <indexterm>
149
+ <primary>polymorphic functions</primary>
150
+ </indexterm>
151
+
152
+ <para>
153
+ Two pseudo-types of special interest are <type>anyelement</> and
154
+ <type>anyarray</>, which are collectively called <firstterm>polymorphic
155
+ types</>. Any function declared using these types is said to be
156
+ a <firstterm>polymorphic function</>. A polymorphic function can
157
+ operate on many different data types, with the specific data type(s)
158
+ being determined by the data types actually passed to it in a particular
159
+ call.
160
+ </para>
161
+
162
+ <para>
163
+ Polymorphic arguments and results are tied to each other and are resolved
164
+ to a specific data type when a query calling a polymorphic function is
165
+ parsed. Each position (either argument or return value) declared as
166
+ <type>anyelement</type> is allowed to have any specific actual
167
+ data type, but in any given call they must all be the
168
+ <emphasis>same</emphasis> actual type. Each
169
+ position declared as <type>anyarray</type> can have any array data type,
170
+ but similarly they must all be the same type. If there are
171
+ positions declared <type>anyarray</type> and others declared
172
+ <type>anyelement</type>, the actual array type in the
173
+ <type>anyarray</type> positions must be an array whose elements are
174
+ the same type appearing in the <type>anyelement</type> positions.
175
+ </para>
176
+
177
+ <para>
178
+ Thus, when more than one argument position is declared with a polymorphic
179
+ type, the net effect is that only certain combinations of actual argument
180
+ types are allowed. For example, a function declared as
181
+ <literal>foo(anyelement, anyelement)</> will take any two input values,
182
+ so long as they are of the same data type.
183
+ </para>
184
+
185
+ <para>
186
+ When the return value of a function is declared as a polymorphic type,
187
+ there must be at least one argument position that is also polymorphic,
188
+ and the actual data type supplied as the argument determines the actual
189
+ result type for that call. For example, if there were not already
190
+ an array subscripting mechanism, one could define a function that
191
+ implements subscripting as <literal>subscript(anyarray, integer)
192
+ returns anyelement</>. This declaration constrains the actual first
193
+ argument to be an array type, and allows the parser to infer the correct
194
+ result type from the actual first argument's type.
195
+ </para>
196
+ </sect2>
103
197
</sect1>
104
198
105
199
&xfunc;
200
+ &xaggr;
106
201
&xtypes;
107
202
&xoper;
108
- &xaggr;
109
203
&xindex;
110
204
111
205
</chapter>