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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>10.4.Value Storage</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="typeconv.html" title="Chapter10.Type Conversion">
<link rel="prev" href="typeconv-func.html" title="10.3.Functions">
<link rel="next" href="typeconv-union-case.html" title="10.5.UNION, CASE, and Related Constructs">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="typeconv-query"></a>10.4.Value Storage</h2></div></div></div>
<p> Values to be inserted into a table are converted to the destination
column's data type according to the
following steps.
</p>
<div class="procedure">
<a name="id627154"></a><p class="title"><b>Value Storage Type Conversion</b></p>
<ol type="1">
<li><p>Check for an exact match with the target.</p></li>
<li><p>Otherwise, try to convert the expression to the target type. This will succeed
if there is a registered cast between the two types.
If the expression is an unknown-type literal, the contents of
the literal string will be fed to the input conversion routine for the target
type.</p></li>
<li><p>Check to see if there is a sizing cast for the target type. A sizing
cast is a cast from that type to itself. If one is found in the
<code class="structname">pg_cast</code> catalog, apply it to the expression before storing
into the destination column. The implementation function for such a cast
always takes an extra parameter of type <code class="type">integer</code>, which receives
the destination column's declared length (actually, its
<code class="structfield">atttypmod</code> value; the interpretation of
<code class="structfield">atttypmod</code> varies for different data types). The cast function
is responsible for applying any length-dependent semantics such as size
checking or truncation.</p></li>
</ol>
</div>
<div class="example">
<a name="id627208"></a><p class="title"><b>Example10.6.<code class="type">character</code> Storage Type Conversion</b></p>
<div class="example-contents">
<p>For a target column declared as <code class="type">character(20)</code> the following statement
ensures that the stored value is sized correctly:
</p>
<pre class="screen">CREATE TABLE vv (v character(20));
INSERT INTO vv SELECT 'abc' || 'def';
SELECT v, length(v) FROM vv;
v | length
----------------------+--------
abcdef | 20
(1 row)</pre>
<p>What has really happened here is that the two unknown literals are resolved
to <code class="type">text</code> by default, allowing the <code class="literal">||</code> operator
to be resolved as <code class="type">text</code> concatenation. Then the <code class="type">text</code>
result of the operator is converted to <code class="type">bpchar</code> (“<span class="quote">blank-padded
char</span>”, the internal name of the <code class="type">character</code> data type) to match the target
column type. (Since the types <code class="type">text</code> and
<code class="type">bpchar</code> are binary-compatible, this conversion does
not insert any real function call.) Finally, the sizing function
<code class="literal">bpchar(bpchar, integer)</code> is found in the system catalog
and applied to the operator's result and the stored column length. This
type-specific function performs the required length check and addition of
padding spaces.</p>
</div>
</div>
<br class="example-break">
</div></body>
</html>
|
