|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
2 |
<HTML |
|
3 |
><HEAD |
|
4 |
><TITLE |
|
5 |
>The PostgreSQL Type System</TITLE |
|
6 |
><META |
|
7 |
NAME="GENERATOR" |
|
8 |
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK |
|
9 |
REV="MADE" |
|
10 |
HREF="mailto:pgsql-docs@postgresql.org"><LINK |
|
11 |
REL="HOME" |
|
|
1.1.11
by Martin Pitt
Import upstream version 9.3.12 |
12 |
TITLE="PostgreSQL 9.3.12 Documentation" |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
13 |
HREF="index.html"><LINK |
14 |
REL="UP" |
|
15 |
TITLE="Extending SQL" |
|
16 |
HREF="extend.html"><LINK |
|
17 |
REL="PREVIOUS" |
|
18 |
TITLE="How Extensibility Works" |
|
19 |
HREF="extend-how.html"><LINK |
|
20 |
REL="NEXT" |
|
21 |
TITLE="User-defined Functions" |
|
22 |
HREF="xfunc.html"><LINK |
|
23 |
REL="STYLESHEET" |
|
24 |
TYPE="text/css" |
|
25 |
HREF="stylesheet.css"><META |
|
26 |
HTTP-EQUIV="Content-Type" |
|
27 |
CONTENT="text/html; charset=ISO-8859-1"><META |
|
28 |
NAME="creation" |
|
|
1.1.11
by Martin Pitt
Import upstream version 9.3.12 |
29 |
CONTENT="2016-03-28T20:28:06"></HEAD |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
30 |
><BODY |
31 |
CLASS="SECT1" |
|
32 |
><DIV |
|
33 |
CLASS="NAVHEADER" |
|
34 |
><TABLE |
|
35 |
SUMMARY="Header navigation table" |
|
36 |
WIDTH="100%" |
|
37 |
BORDER="0" |
|
38 |
CELLPADDING="0" |
|
39 |
CELLSPACING="0" |
|
40 |
><TR |
|
41 |
><TH |
|
42 |
COLSPAN="5" |
|
43 |
ALIGN="center" |
|
44 |
VALIGN="bottom" |
|
45 |
><A |
|
46 |
HREF="index.html" |
|
|
1.1.11
by Martin Pitt
Import upstream version 9.3.12 |
47 |
>PostgreSQL 9.3.12 Documentation</A |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
48 |
></TH |
49 |
></TR |
|
50 |
><TR |
|
51 |
><TD |
|
52 |
WIDTH="10%" |
|
53 |
ALIGN="left" |
|
54 |
VALIGN="top" |
|
55 |
><A |
|
56 |
TITLE="How Extensibility Works" |
|
57 |
HREF="extend-how.html" |
|
58 |
ACCESSKEY="P" |
|
59 |
>Prev</A |
|
60 |
></TD |
|
61 |
><TD |
|
62 |
WIDTH="10%" |
|
63 |
ALIGN="left" |
|
64 |
VALIGN="top" |
|
65 |
><A |
|
66 |
HREF="extend.html" |
|
67 |
ACCESSKEY="U" |
|
68 |
>Up</A |
|
69 |
></TD |
|
70 |
><TD |
|
71 |
WIDTH="60%" |
|
72 |
ALIGN="center" |
|
73 |
VALIGN="bottom" |
|
74 |
>Chapter 35. Extending <ACRONYM |
|
75 |
CLASS="ACRONYM" |
|
76 |
>SQL</ACRONYM |
|
77 |
></TD |
|
78 |
><TD |
|
79 |
WIDTH="20%" |
|
80 |
ALIGN="right" |
|
81 |
VALIGN="top" |
|
82 |
><A |
|
83 |
TITLE="User-defined Functions" |
|
84 |
HREF="xfunc.html" |
|
85 |
ACCESSKEY="N" |
|
86 |
>Next</A |
|
87 |
></TD |
|
88 |
></TR |
|
89 |
></TABLE |
|
90 |
><HR |
|
91 |
ALIGN="LEFT" |
|
92 |
WIDTH="100%"></DIV |
|
93 |
><DIV |
|
94 |
CLASS="SECT1" |
|
95 |
><H1 |
|
96 |
CLASS="SECT1" |
|
97 |
><A |
|
98 |
NAME="EXTEND-TYPE-SYSTEM" |
|
99 |
>35.2. The <SPAN |
|
100 |
CLASS="PRODUCTNAME" |
|
101 |
>PostgreSQL</SPAN |
|
102 |
> Type System</A |
|
103 |
></H1 |
|
104 |
><P |
|
105 |
> <SPAN |
|
106 |
CLASS="PRODUCTNAME" |
|
107 |
>PostgreSQL</SPAN |
|
108 |
> data types are divided into base
|
|
109 |
types, composite types, domains, and pseudo-types. |
|
110 |
</P |
|
111 |
><DIV |
|
112 |
CLASS="SECT2" |
|
113 |
><H2 |
|
114 |
CLASS="SECT2" |
|
115 |
><A |
|
|
1.2.4
by Martin Pitt
Import upstream version 9.3.11 |
116 |
NAME="AEN52900" |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
117 |
>35.2.1. Base Types</A |
118 |
></H2 |
|
119 |
><P |
|
120 |
> Base types are those, like <TT |
|
121 |
CLASS="TYPE" |
|
122 |
>int4</TT |
|
123 |
>, that are
|
|
124 |
implemented below the level of the <ACRONYM |
|
125 |
CLASS="ACRONYM" |
|
126 |
>SQL</ACRONYM |
|
127 |
> language
|
|
128 |
(typically in a low-level language such as C). They generally |
|
129 |
correspond to what are often known as abstract data types. |
|
130 |
<SPAN |
|
131 |
CLASS="PRODUCTNAME" |
|
132 |
>PostgreSQL</SPAN |
|
133 |
> can only operate on such
|
|
134 |
types through functions provided by the user and only understands |
|
135 |
the behavior of such types to the extent that the user describes |
|
136 |
them. Base types are further subdivided into scalar and array |
|
137 |
types. For each scalar type, a corresponding array type is |
|
138 |
automatically created that can hold variable-size arrays of that |
|
139 |
scalar type. |
|
140 |
</P |
|
141 |
></DIV |
|
142 |
><DIV |
|
143 |
CLASS="SECT2" |
|
144 |
><H2 |
|
145 |
CLASS="SECT2" |
|
146 |
><A |
|
|
1.2.4
by Martin Pitt
Import upstream version 9.3.11 |
147 |
NAME="AEN52906" |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
148 |
>35.2.2. Composite Types</A |
149 |
></H2 |
|
150 |
><P |
|
151 |
> Composite types, or row types, are created whenever the user
|
|
152 |
creates a table. It is also possible to use <A |
|
153 |
HREF="sql-createtype.html" |
|
154 |
>CREATE TYPE</A |
|
155 |
> to
|
|
156 |
define a <SPAN |
|
157 |
CLASS="QUOTE" |
|
158 |
>"stand-alone"</SPAN |
|
159 |
> composite type with no associated
|
|
160 |
table. A composite type is simply a list of types with |
|
161 |
associated field names. A value of a composite type is a row or |
|
162 |
record of field values. The user can access the component fields |
|
163 |
from <ACRONYM |
|
164 |
CLASS="ACRONYM" |
|
165 |
>SQL</ACRONYM |
|
166 |
> queries. Refer to <A |
|
167 |
HREF="rowtypes.html" |
|
168 |
>Section 8.16</A |
|
169 |
>
|
|
170 |
for more information on composite types. |
|
171 |
</P |
|
172 |
></DIV |
|
173 |
><DIV |
|
174 |
CLASS="SECT2" |
|
175 |
><H2 |
|
176 |
CLASS="SECT2" |
|
177 |
><A |
|
|
1.1.1
by Martin Pitt
Import upstream version 9.3~beta2 |
178 |
NAME="EXTEND-TYPE-SYSTEM-DOMAINS" |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
179 |
>35.2.3. Domains</A |
180 |
></H2 |
|
181 |
><P |
|
182 |
> A domain is based on a particular base type and for many purposes
|
|
183 |
is interchangeable with its base type. However, a domain can |
|
184 |
have constraints that restrict its valid values to a subset of |
|
185 |
what the underlying base type would allow. |
|
186 |
</P |
|
187 |
><P |
|
188 |
> Domains can be created using the <ACRONYM |
|
189 |
CLASS="ACRONYM" |
|
190 |
>SQL</ACRONYM |
|
191 |
> command
|
|
192 |
<A |
|
193 |
HREF="sql-createdomain.html" |
|
194 |
>CREATE DOMAIN</A |
|
195 |
>.
|
|
196 |
Their creation and use is not discussed in this chapter. |
|
197 |
</P |
|
198 |
></DIV |
|
199 |
><DIV |
|
200 |
CLASS="SECT2" |
|
201 |
><H2 |
|
202 |
CLASS="SECT2" |
|
203 |
><A |
|
|
1.2.4
by Martin Pitt
Import upstream version 9.3.11 |
204 |
NAME="AEN52919" |
|
1
by Martin Pitt
Import upstream version 9.3~beta1 |
205 |
>35.2.4. Pseudo-Types</A |
206 |
></H2 |
|
207 |
><P |
|
208 |
> There are a few <SPAN |
|
209 |
CLASS="QUOTE" |
|
210 |
>"pseudo-types"</SPAN |
|
211 |
> for special purposes.
|
|
212 |
Pseudo-types cannot appear as columns of tables or attributes of |
|
213 |
composite types, but they can be used to declare the argument and |
|
214 |
result types of functions. This provides a mechanism within the |
|
215 |
type system to identify special classes of functions. <A |
|
216 |
HREF="datatype-pseudo.html#DATATYPE-PSEUDOTYPES-TABLE" |
|
217 |
>Table 8-24</A |
|
218 |
> lists the existing
|
|
219 |
pseudo-types. |
|
220 |
</P |
|
221 |
></DIV |
|
222 |
><DIV |
|
223 |
CLASS="SECT2" |
|
224 |
><H2 |
|
225 |
CLASS="SECT2" |
|
226 |
><A |
|
227 |
NAME="EXTEND-TYPES-POLYMORPHIC" |
|
228 |
>35.2.5. Polymorphic Types</A |
|
229 |
></H2 |
|
230 |
><P |
|
231 |
> Five pseudo-types of special interest are <TT |
|
232 |
CLASS="TYPE" |
|
233 |
>anyelement</TT |
|
234 |
>,
|
|
235 |
<TT |
|
236 |
CLASS="TYPE" |
|
237 |
>anyarray</TT |
|
238 |
>, <TT |
|
239 |
CLASS="TYPE" |
|
240 |
>anynonarray</TT |
|
241 |
>, <TT |
|
242 |
CLASS="TYPE" |
|
243 |
>anyenum</TT |
|
244 |
>,
|
|
245 |
and <TT |
|
246 |
CLASS="TYPE" |
|
247 |
>anyrange</TT |
|
248 |
>,
|
|
249 |
which are collectively called <I |
|
250 |
CLASS="FIRSTTERM" |
|
251 |
>polymorphic types</I |
|
252 |
>.
|
|
253 |
Any function declared using these types is said to be |
|
254 |
a <I |
|
255 |
CLASS="FIRSTTERM" |
|
256 |
>polymorphic function</I |
|
257 |
>. A polymorphic function can
|
|
258 |
operate on many different data types, with the specific data type(s) |
|
259 |
being determined by the data types actually passed to it in a particular |
|
260 |
call. |
|
261 |
</P |
|
262 |
><P |
|
263 |
> Polymorphic arguments and results are tied to each other and are resolved
|
|
264 |
to a specific data type when a query calling a polymorphic function is |
|
265 |
parsed. Each position (either argument or return value) declared as |
|
266 |
<TT |
|
267 |
CLASS="TYPE" |
|
268 |
>anyelement</TT |
|
269 |
> is allowed to have any specific actual
|
|
270 |
data type, but in any given call they must all be the |
|
271 |
<SPAN |
|
272 |
CLASS="emphasis" |
|
273 |
><I |
|
274 |
CLASS="EMPHASIS" |
|
275 |
>same</I |
|
276 |
></SPAN |
|
277 |
> actual type. Each
|
|
278 |
position declared as <TT |
|
279 |
CLASS="TYPE" |
|
280 |
>anyarray</TT |
|
281 |
> can have any array data type,
|
|
282 |
but similarly they must all be the same type. And similarly, |
|
283 |
positions declared as <TT |
|
284 |
CLASS="TYPE" |
|
285 |
>anyrange</TT |
|
286 |
> must all be the same range
|
|
287 |
type. Furthermore, if there are |
|
288 |
positions declared <TT |
|
289 |
CLASS="TYPE" |
|
290 |
>anyarray</TT |
|
291 |
> and others declared
|
|
292 |
<TT |
|
293 |
CLASS="TYPE" |
|
294 |
>anyelement</TT |
|
295 |
>, the actual array type in the
|
|
296 |
<TT |
|
297 |
CLASS="TYPE" |
|
298 |
>anyarray</TT |
|
299 |
> positions must be an array whose elements are
|
|
300 |
the same type appearing in the <TT |
|
301 |
CLASS="TYPE" |
|
302 |
>anyelement</TT |
|
303 |
> positions.
|
|
304 |
Similarly, if there are positions declared <TT |
|
305 |
CLASS="TYPE" |
|
306 |
>anyrange</TT |
|
307 |
>
|
|
308 |
and others declared <TT |
|
309 |
CLASS="TYPE" |
|
310 |
>anyelement</TT |
|
311 |
>, the actual range type in
|
|
312 |
the <TT |
|
313 |
CLASS="TYPE" |
|
314 |
>anyrange</TT |
|
315 |
> positions must be a range whose subtype is
|
|
316 |
the same type appearing in the <TT |
|
317 |
CLASS="TYPE" |
|
318 |
>anyelement</TT |
|
319 |
> positions.
|
|
320 |
<TT |
|
321 |
CLASS="TYPE" |
|
322 |
>anynonarray</TT |
|
323 |
> is treated exactly the same as <TT |
|
324 |
CLASS="TYPE" |
|
325 |
>anyelement</TT |
|
326 |
>,
|
|
327 |
but adds the additional constraint that the actual type must not be |
|
328 |
an array type. |
|
329 |
<TT |
|
330 |
CLASS="TYPE" |
|
331 |
>anyenum</TT |
|
332 |
> is treated exactly the same as <TT |
|
333 |
CLASS="TYPE" |
|
334 |
>anyelement</TT |
|
335 |
>,
|
|
336 |
but adds the additional constraint that the actual type must |
|
337 |
be an enum type. |
|
338 |
</P |
|
339 |
><P |
|
340 |
> Thus, when more than one argument position is declared with a polymorphic
|
|
341 |
type, the net effect is that only certain combinations of actual argument |
|
342 |
types are allowed. For example, a function declared as |
|
343 |
<TT |
|
344 |
CLASS="LITERAL" |
|
345 |
>equal(anyelement, anyelement)</TT |
|
346 |
> will take any two input values,
|
|
347 |
so long as they are of the same data type. |
|
348 |
</P |
|
349 |
><P |
|
350 |
> When the return value of a function is declared as a polymorphic type,
|
|
351 |
there must be at least one argument position that is also polymorphic, |
|
352 |
and the actual data type supplied as the argument determines the actual |
|
353 |
result type for that call. For example, if there were not already |
|
354 |
an array subscripting mechanism, one could define a function that |
|
355 |
implements subscripting as <TT |
|
356 |
CLASS="LITERAL" |
|
357 |
>subscript(anyarray, integer)
|
|
358 |
returns anyelement</TT |
|
359 |
>. This declaration constrains the actual first
|
|
360 |
argument to be an array type, and allows the parser to infer the correct |
|
361 |
result type from the actual first argument's type. Another example |
|
362 |
is that a function declared as <TT |
|
363 |
CLASS="LITERAL" |
|
364 |
>f(anyarray) returns anyenum</TT |
|
365 |
>
|
|
366 |
will only accept arrays of enum types. |
|
367 |
</P |
|
368 |
><P |
|
369 |
> Note that <TT |
|
370 |
CLASS="TYPE" |
|
371 |
>anynonarray</TT |
|
372 |
> and <TT |
|
373 |
CLASS="TYPE" |
|
374 |
>anyenum</TT |
|
375 |
> do not represent
|
|
376 |
separate type variables; they are the same type as |
|
377 |
<TT |
|
378 |
CLASS="TYPE" |
|
379 |
>anyelement</TT |
|
380 |
>, just with an additional constraint. For
|
|
381 |
example, declaring a function as <TT |
|
382 |
CLASS="LITERAL" |
|
383 |
>f(anyelement, anyenum)</TT |
|
384 |
>
|
|
385 |
is equivalent to declaring it as <TT |
|
386 |
CLASS="LITERAL" |
|
387 |
>f(anyenum, anyenum)</TT |
|
388 |
>:
|
|
389 |
both actual arguments have to be the same enum type. |
|
390 |
</P |
|
391 |
><P |
|
392 |
> A variadic function (one taking a variable number of arguments, as in
|
|
393 |
<A |
|
394 |
HREF="xfunc-sql.html#XFUNC-SQL-VARIADIC-FUNCTIONS" |
|
395 |
>Section 35.4.5</A |
|
396 |
>) can be
|
|
397 |
polymorphic: this is accomplished by declaring its last parameter as |
|
398 |
<TT |
|
399 |
CLASS="LITERAL" |
|
400 |
>VARIADIC</TT |
|
401 |
> <TT |
|
402 |
CLASS="TYPE" |
|
403 |
>anyarray</TT |
|
404 |
>. For purposes of argument
|
|
405 |
matching and determining the actual result type, such a function behaves |
|
406 |
the same as if you had written the appropriate number of |
|
407 |
<TT |
|
408 |
CLASS="TYPE" |
|
409 |
>anynonarray</TT |
|
410 |
> parameters.
|
|
411 |
</P |
|
412 |
></DIV |
|
413 |
></DIV |
|
414 |
><DIV |
|
415 |
CLASS="NAVFOOTER" |
|
416 |
><HR |
|
417 |
ALIGN="LEFT" |
|
418 |
WIDTH="100%"><TABLE |
|
419 |
SUMMARY="Footer navigation table" |
|
420 |
WIDTH="100%" |
|
421 |
BORDER="0" |
|
422 |
CELLPADDING="0" |
|
423 |
CELLSPACING="0" |
|
424 |
><TR |
|
425 |
><TD |
|
426 |
WIDTH="33%" |
|
427 |
ALIGN="left" |
|
428 |
VALIGN="top" |
|
429 |
><A |
|
430 |
HREF="extend-how.html" |
|
431 |
ACCESSKEY="P" |
|
432 |
>Prev</A |
|
433 |
></TD |
|
434 |
><TD |
|
435 |
WIDTH="34%" |
|
436 |
ALIGN="center" |
|
437 |
VALIGN="top" |
|
438 |
><A |
|
439 |
HREF="index.html" |
|
440 |
ACCESSKEY="H" |
|
441 |
>Home</A |
|
442 |
></TD |
|
443 |
><TD |
|
444 |
WIDTH="33%" |
|
445 |
ALIGN="right" |
|
446 |
VALIGN="top" |
|
447 |
><A |
|
448 |
HREF="xfunc.html" |
|
449 |
ACCESSKEY="N" |
|
450 |
>Next</A |
|
451 |
></TD |
|
452 |
></TR |
|
453 |
><TR |
|
454 |
><TD |
|
455 |
WIDTH="33%" |
|
456 |
ALIGN="left" |
|
457 |
VALIGN="top" |
|
458 |
>How Extensibility Works</TD |
|
459 |
><TD |
|
460 |
WIDTH="34%" |
|
461 |
ALIGN="center" |
|
462 |
VALIGN="top" |
|
463 |
><A |
|
464 |
HREF="extend.html" |
|
465 |
ACCESSKEY="U" |
|
466 |
>Up</A |
|
467 |
></TD |
|
468 |
><TD |
|
469 |
WIDTH="33%" |
|
470 |
ALIGN="right" |
|
471 |
VALIGN="top" |
|
472 |
>User-defined Functions</TD |
|
473 |
></TR |
|
474 |
></TABLE |
|
475 |
></DIV |
|
476 |
></BODY |
|
477 |
></HTML |
|
478 |
>
|