← Back to branch summary

~ubuntu-branches/ubuntu/precise/postgresql-9.1/precise-security

« back to all changes in this revision

Viewing changes to doc/src/sgml/html/typeconv-overview.html

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2011-05-11 10:41:53 UTC
  • Revision ID: james.westby@ubuntu.com-20110511104153-psbh2o58553fv1m0
Tags: upstream-9.1~beta1
Import upstream version 9.1~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/html/typeconv-overview.html
 
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
>Overview</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"
 
12
TITLE="PostgreSQL 9.1beta1 Documentation"
 
13
HREF="index.html"><LINK
 
14
REL="UP"
 
15
TITLE="Type Conversion"
 
16
HREF="typeconv.html"><LINK
 
17
REL="PREVIOUS"
 
18
TITLE="Type Conversion"
 
19
HREF="typeconv.html"><LINK
 
20
REL="NEXT"
 
21
TITLE="Operators"
 
22
HREF="typeconv-oper.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"
 
29
CONTENT="2011-04-27T21:20:33"></HEAD
 
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"
 
47
>PostgreSQL 9.1beta1 Documentation</A
 
48
></TH
 
49
></TR
 
50
><TR
 
51
><TD
 
52
WIDTH="10%"
 
53
ALIGN="left"
 
54
VALIGN="top"
 
55
><A
 
56
TITLE="Type Conversion"
 
57
HREF="typeconv.html"
 
58
ACCESSKEY="P"
 
59
>Prev</A
 
60
></TD
 
61
><TD
 
62
WIDTH="10%"
 
63
ALIGN="left"
 
64
VALIGN="top"
 
65
><A
 
66
TITLE="Type Conversion"
 
67
HREF="typeconv.html"
 
68
>Fast Backward</A
 
69
></TD
 
70
><TD
 
71
WIDTH="60%"
 
72
ALIGN="center"
 
73
VALIGN="bottom"
 
74
>Chapter 10. Type Conversion</TD
 
75
><TD
 
76
WIDTH="10%"
 
77
ALIGN="right"
 
78
VALIGN="top"
 
79
><A
 
80
TITLE="Type Conversion"
 
81
HREF="typeconv.html"
 
82
>Fast Forward</A
 
83
></TD
 
84
><TD
 
85
WIDTH="10%"
 
86
ALIGN="right"
 
87
VALIGN="top"
 
88
><A
 
89
TITLE="Operators"
 
90
HREF="typeconv-oper.html"
 
91
ACCESSKEY="N"
 
92
>Next</A
 
93
></TD
 
94
></TR
 
95
></TABLE
 
96
><HR
 
97
ALIGN="LEFT"
 
98
WIDTH="100%"></DIV
 
99
><DIV
 
100
CLASS="SECT1"
 
101
><H1
 
102
CLASS="SECT1"
 
103
><A
 
104
NAME="TYPECONV-OVERVIEW"
 
105
>10.1. Overview</A
 
106
></H1
 
107
><P
 
108
><ACRONYM
 
109
CLASS="ACRONYM"
 
110
>SQL</ACRONYM
 
111
> is a strongly typed language. That is, every data item
 
112
has an associated data type which determines its behavior and allowed usage.
 
113
<SPAN
 
114
CLASS="PRODUCTNAME"
 
115
>PostgreSQL</SPAN
 
116
> has an extensible type system that is
 
117
more general and flexible than other <ACRONYM
 
118
CLASS="ACRONYM"
 
119
>SQL</ACRONYM
 
120
> implementations.
 
121
Hence, most type conversion behavior in <SPAN
 
122
CLASS="PRODUCTNAME"
 
123
>PostgreSQL</SPAN
 
124
>
 
125
is governed by general rules rather than by <I
 
126
CLASS="FOREIGNPHRASE"
 
127
>ad hoc</I
 
128
>
 
129
heuristics.  This allows the use of mixed-type expressions even with
 
130
user-defined types.</P
 
131
><P
 
132
>The <SPAN
 
133
CLASS="PRODUCTNAME"
 
134
>PostgreSQL</SPAN
 
135
> scanner/parser divides lexical
 
136
elements into five fundamental categories: integers, non-integer numbers,
 
137
strings, identifiers, and key words.  Constants of most non-numeric types are
 
138
first classified as strings. The <ACRONYM
 
139
CLASS="ACRONYM"
 
140
>SQL</ACRONYM
 
141
> language definition
 
142
allows specifying type names with strings, and this mechanism can be used in
 
143
<SPAN
 
144
CLASS="PRODUCTNAME"
 
145
>PostgreSQL</SPAN
 
146
> to start the parser down the correct
 
147
path. For example, the query:
 
148
 
 
149
</P><PRE
 
150
CLASS="SCREEN"
 
151
>SELECT text 'Origin' AS "label", point '(0,0)' AS "value";
 
152
 
 
153
 label  | value
 
154
--------+-------
 
155
 Origin | (0,0)
 
156
(1 row)</PRE
 
157
><P>
 
158
 
 
159
has two literal constants, of type <TT
 
160
CLASS="TYPE"
 
161
>text</TT
 
162
> and <TT
 
163
CLASS="TYPE"
 
164
>point</TT
 
165
>.
 
166
If a type is not specified for a string literal, then the placeholder type
 
167
<TT
 
168
CLASS="TYPE"
 
169
>unknown</TT
 
170
> is assigned initially, to be resolved in later
 
171
stages as described below.</P
 
172
><P
 
173
>There are four fundamental <ACRONYM
 
174
CLASS="ACRONYM"
 
175
>SQL</ACRONYM
 
176
> constructs requiring
 
177
distinct type conversion rules in the <SPAN
 
178
CLASS="PRODUCTNAME"
 
179
>PostgreSQL</SPAN
 
180
>
 
181
parser:
 
182
 
 
183
<P
 
184
></P
 
185
></P><DIV
 
186
CLASS="VARIABLELIST"
 
187
><DL
 
188
><DT
 
189
>Function calls</DT
 
190
><DD
 
191
><P
 
192
>Much of the <SPAN
 
193
CLASS="PRODUCTNAME"
 
194
>PostgreSQL</SPAN
 
195
> type system is built around a
 
196
rich set of functions. Functions can have one or more arguments.
 
197
Since <SPAN
 
198
CLASS="PRODUCTNAME"
 
199
>PostgreSQL</SPAN
 
200
> permits function
 
201
overloading, the function name alone does not uniquely identify the function
 
202
to be called; the parser must select the right function based on the data
 
203
types of the supplied arguments.</P
 
204
></DD
 
205
><DT
 
206
>Operators</DT
 
207
><DD
 
208
><P
 
209
><SPAN
 
210
CLASS="PRODUCTNAME"
 
211
>PostgreSQL</SPAN
 
212
> allows expressions with
 
213
prefix and postfix unary (one-argument) operators,
 
214
as well as binary (two-argument) operators.  Like functions, operators can
 
215
be overloaded, so the same problem of selecting the right operator
 
216
exists.</P
 
217
></DD
 
218
><DT
 
219
>Value Storage</DT
 
220
><DD
 
221
><P
 
222
><ACRONYM
 
223
CLASS="ACRONYM"
 
224
>SQL</ACRONYM
 
225
> <TT
 
226
CLASS="COMMAND"
 
227
>INSERT</TT
 
228
> and <TT
 
229
CLASS="COMMAND"
 
230
>UPDATE</TT
 
231
> statements place the results of
 
232
expressions into a table. The expressions in the statement must be matched up
 
233
with, and perhaps converted to, the types of the target columns.</P
 
234
></DD
 
235
><DT
 
236
><TT
 
237
CLASS="LITERAL"
 
238
>UNION</TT
 
239
>, <TT
 
240
CLASS="LITERAL"
 
241
>CASE</TT
 
242
>, and related constructs</DT
 
243
><DD
 
244
><P
 
245
>Since all query results from a unionized <TT
 
246
CLASS="COMMAND"
 
247
>SELECT</TT
 
248
> statement
 
249
must appear in a single set of columns, the types of the results of each
 
250
<TT
 
251
CLASS="COMMAND"
 
252
>SELECT</TT
 
253
> clause must be matched up and converted to a uniform set.
 
254
Similarly, the result expressions of a <TT
 
255
CLASS="LITERAL"
 
256
>CASE</TT
 
257
> construct must be
 
258
converted to a common type so that the <TT
 
259
CLASS="LITERAL"
 
260
>CASE</TT
 
261
> expression as a whole
 
262
has a known output type.  The same holds for <TT
 
263
CLASS="LITERAL"
 
264
>ARRAY</TT
 
265
> constructs,
 
266
and for the <CODE
 
267
CLASS="FUNCTION"
 
268
>GREATEST</CODE
 
269
> and <CODE
 
270
CLASS="FUNCTION"
 
271
>LEAST</CODE
 
272
> functions.</P
 
273
></DD
 
274
></DL
 
275
></DIV
 
276
><P></P
 
277
><P
 
278
>The system catalogs store information about which conversions, or
 
279
<I
 
280
CLASS="FIRSTTERM"
 
281
>casts</I
 
282
>, exist between which data types, and how to
 
283
perform those conversions.  Additional casts can be added by the user
 
284
with the <A
 
285
HREF="sql-createcast.html"
 
286
>CREATE CAST</A
 
287
>
 
288
command.  (This is usually
 
289
done in conjunction with defining new data types.  The set of casts
 
290
between built-in types has been carefully crafted and is best not
 
291
altered.)</P
 
292
><P
 
293
>An additional heuristic provided by the parser allows improved determination
 
294
of the proper casting behavior among groups of types that have implicit casts.
 
295
Data types are divided into several basic <I
 
296
CLASS="FIRSTTERM"
 
297
>type
 
298
categories</I
 
299
>, including <TT
 
300
CLASS="TYPE"
 
301
>boolean</TT
 
302
>, <TT
 
303
CLASS="TYPE"
 
304
>numeric</TT
 
305
>,
 
306
<TT
 
307
CLASS="TYPE"
 
308
>string</TT
 
309
>, <TT
 
310
CLASS="TYPE"
 
311
>bitstring</TT
 
312
>, <TT
 
313
CLASS="TYPE"
 
314
>datetime</TT
 
315
>,
 
316
<TT
 
317
CLASS="TYPE"
 
318
>timespan</TT
 
319
>, <TT
 
320
CLASS="TYPE"
 
321
>geometric</TT
 
322
>, <TT
 
323
CLASS="TYPE"
 
324
>network</TT
 
325
>, and
 
326
user-defined.  (For a list see <A
 
327
HREF="catalog-pg-type.html#CATALOG-TYPCATEGORY-TABLE"
 
328
>Table 45-49</A
 
329
>;
 
330
but note it is also possible to create custom type categories.)  Within each
 
331
category there can be one or more <I
 
332
CLASS="FIRSTTERM"
 
333
>preferred types</I
 
334
>, which
 
335
are preferred when there is a choice of possible types.  With careful selection
 
336
of preferred types and available implicit casts, it is possible to ensure that
 
337
ambiguous expressions (those with multiple candidate parsing solutions) can be
 
338
resolved in a useful way.</P
 
339
><P
 
340
>All type conversion rules are designed with several principles in mind:
 
341
 
 
342
<P
 
343
></P
 
344
></P><UL
 
345
><LI
 
346
><P
 
347
>Implicit conversions should never have surprising or unpredictable outcomes.</P
 
348
></LI
 
349
><LI
 
350
><P
 
351
>There should be no extra overhead in the parser or executor
 
352
if a query does not need implicit type conversion.
 
353
That is, if a query is well-formed and the types already match, then the query should execute
 
354
without spending extra time in the parser and without introducing unnecessary implicit conversion
 
355
calls in the query.</P
 
356
><P
 
357
>Additionally, if a query usually requires an implicit conversion for a function, and
 
358
if then the user defines a new function with the correct argument types, the parser
 
359
should use this new function and no longer do implicit conversion to use the old function.</P
 
360
></LI
 
361
></UL
 
362
><P></P
 
363
></DIV
 
364
><DIV
 
365
CLASS="NAVFOOTER"
 
366
><HR
 
367
ALIGN="LEFT"
 
368
WIDTH="100%"><TABLE
 
369
SUMMARY="Footer navigation table"
 
370
WIDTH="100%"
 
371
BORDER="0"
 
372
CELLPADDING="0"
 
373
CELLSPACING="0"
 
374
><TR
 
375
><TD
 
376
WIDTH="33%"
 
377
ALIGN="left"
 
378
VALIGN="top"
 
379
><A
 
380
HREF="typeconv.html"
 
381
ACCESSKEY="P"
 
382
>Prev</A
 
383
></TD
 
384
><TD
 
385
WIDTH="34%"
 
386
ALIGN="center"
 
387
VALIGN="top"
 
388
><A
 
389
HREF="index.html"
 
390
ACCESSKEY="H"
 
391
>Home</A
 
392
></TD
 
393
><TD
 
394
WIDTH="33%"
 
395
ALIGN="right"
 
396
VALIGN="top"
 
397
><A
 
398
HREF="typeconv-oper.html"
 
399
ACCESSKEY="N"
 
400
>Next</A
 
401
></TD
 
402
></TR
 
403
><TR
 
404
><TD
 
405
WIDTH="33%"
 
406
ALIGN="left"
 
407
VALIGN="top"
 
408
>Type Conversion</TD
 
409
><TD
 
410
WIDTH="34%"
 
411
ALIGN="center"
 
412
VALIGN="top"
 
413
><A
 
414
HREF="typeconv.html"
 
415
ACCESSKEY="U"
 
416
>Up</A
 
417
></TD
 
418
><TD
 
419
WIDTH="33%"
 
420
ALIGN="right"
 
421
VALIGN="top"
 
422
>Operators</TD
 
423
></TR
 
424
></TABLE
 
425
></DIV
 
426
></BODY
 
427
></HTML
 
428
>
 
 
b'\\ No newline at end of file'