begriffs open source - ai-pg/blob - full-docs/html/typeconv-overview.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>10.1. Overview</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="typeconv.html" title="Chapter 10. Type Conversion" /><link rel="next" href="typeconv-oper.html" title="10.2. Operators" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">10.1. Overview</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="typeconv.html" title="Chapter 10. Type Conversion">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="typeconv.html" title="Chapter 10. Type Conversion">Up</a></td><th width="60%" align="center">Chapter 10. Type Conversion</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="typeconv-oper.html" title="10.2. Operators">Next</a></td></tr></table><hr /></div><div class="sect1" id="TYPECONV-OVERVIEW"><div class="titlepage"><div><div><h2 class="title" style="clear: both">10.1. Overview <a href="#TYPECONV-OVERVIEW" class="id_link">#</a></h2></div></div></div><p>
   3 <acronym class="acronym">SQL</acronym> is a strongly typed language. That is, every data item
   4 has an associated data type which determines its behavior and allowed usage.
   5 <span class="productname">PostgreSQL</span> has an extensible type system that is
   6 more general and flexible than other <acronym class="acronym">SQL</acronym> implementations.
   7 Hence, most type conversion behavior in <span class="productname">PostgreSQL</span>
   8 is governed by general rules rather than by ad hoc
   9 heuristics.  This allows the use of mixed-type expressions even with
  10 user-defined types.
  11 </p><p>
  12 The <span class="productname">PostgreSQL</span> scanner/parser divides lexical
  13 elements into five fundamental categories: integers, non-integer numbers,
  14 strings, identifiers, and key words.  Constants of most non-numeric types are
  15 first classified as strings. The <acronym class="acronym">SQL</acronym> language definition
  16 allows specifying type names with strings, and this mechanism can be used in
  17 <span class="productname">PostgreSQL</span> to start the parser down the correct
  18 path. For example, the query:
  19
  20 </p><pre class="screen">
  21 SELECT text 'Origin' AS "label", point '(0,0)' AS "value";
  22
  23  label  | value
  24 --------+-------
  25  Origin | (0,0)
  26 (1 row)
  27 </pre><p>
  28
  29 has two literal constants, of type <code class="type">text</code> and <code class="type">point</code>.
  30 If a type is not specified for a string literal, then the placeholder type
  31 <code class="type">unknown</code> is assigned initially, to be resolved in later
  32 stages as described below.
  33 </p><p>
  34 There are four fundamental <acronym class="acronym">SQL</acronym> constructs requiring
  35 distinct type conversion rules in the <span class="productname">PostgreSQL</span>
  36 parser:
  37
  38 </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
  39 Function calls
  40 </span></dt><dd><p>
  41 Much of the <span class="productname">PostgreSQL</span> type system is built around a
  42 rich set of functions. Functions can have one or more arguments.
  43 Since <span class="productname">PostgreSQL</span> permits function
  44 overloading, the function name alone does not uniquely identify the function
  45 to be called; the parser must select the right function based on the data
  46 types of the supplied arguments.
  47 </p></dd><dt><span class="term">
  48 Operators
  49 </span></dt><dd><p>
  50 <span class="productname">PostgreSQL</span> allows expressions with
  51 prefix (one-argument) operators,
  52 as well as infix (two-argument) operators.  Like functions, operators can
  53 be overloaded, so the same problem of selecting the right operator
  54 exists.
  55 </p></dd><dt><span class="term">
  56 Value Storage
  57 </span></dt><dd><p>
  58 <acronym class="acronym">SQL</acronym> <code class="command">INSERT</code> and <code class="command">UPDATE</code> statements place the results of
  59 expressions into a table. The expressions in the statement must be matched up
  60 with, and perhaps converted to, the types of the target columns.
  61 </p></dd><dt><span class="term">
  62 <code class="literal">UNION</code>, <code class="literal">CASE</code>, and related constructs
  63 </span></dt><dd><p>
  64 Since all query results from a unionized <code class="command">SELECT</code> statement
  65 must appear in a single set of columns, the types of the results of each
  66 <code class="command">SELECT</code> clause must be matched up and converted to a uniform set.
  67 Similarly, the result expressions of a <code class="literal">CASE</code> construct must be
  68 converted to a common type so that the <code class="literal">CASE</code> expression as a whole
  69 has a known output type.  Some other constructs, such
  70 as <code class="literal">ARRAY[]</code> and the <code class="function">GREATEST</code>
  71 and <code class="function">LEAST</code> functions, likewise require determination of a
  72 common type for several subexpressions.
  73 </p></dd></dl></div><p>
  74 </p><p>
  75 The system catalogs store information about which conversions, or
  76 <em class="firstterm">casts</em>, exist between which data types, and how to
  77 perform those conversions.  Additional casts can be added by the user
  78 with the <a class="xref" href="sql-createcast.html" title="CREATE CAST"><span class="refentrytitle">CREATE CAST</span></a>
  79 command.  (This is usually
  80 done in conjunction with defining new data types.  The set of casts
  81 between built-in types has been carefully crafted and is best not
  82 altered.)
  83 </p><a id="id-1.5.9.6.6" class="indexterm"></a><p>
  84 An additional heuristic provided by the parser allows improved determination
  85 of the proper casting behavior among groups of types that have implicit casts.
  86 Data types are divided into several basic <em class="firstterm">type
  87 categories</em>, including <code class="type">boolean</code>, <code class="type">numeric</code>,
  88 <code class="type">string</code>, <code class="type">bitstring</code>, <code class="type">datetime</code>,
  89 <code class="type">timespan</code>, <code class="type">geometric</code>, <code class="type">network</code>, and
  90 user-defined.  (For a list see <a class="xref" href="catalog-pg-type.html#CATALOG-TYPCATEGORY-TABLE" title="Table 52.65. typcategory Codes">Table 52.65</a>;
  91 but note it is also possible to create custom type categories.)  Within each
  92 category there can be one or more <em class="firstterm">preferred types</em>, which
  93 are preferred when there is a choice of possible types.  With careful selection
  94 of preferred types and available implicit casts, it is possible to ensure that
  95 ambiguous expressions (those with multiple candidate parsing solutions) can be
  96 resolved in a useful way.
  97 </p><p>
  98 All type conversion rules are designed with several principles in mind:
  99
 100 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 101 Implicit conversions should never have surprising or unpredictable outcomes.
 102 </p></li><li class="listitem"><p>
 103 There should be no extra overhead in the parser or executor
 104 if a query does not need implicit type conversion.
 105 That is, if a query is well-formed and the types already match, then the query should execute
 106 without spending extra time in the parser and without introducing unnecessary implicit conversion
 107 calls in the query.
 108 </p></li><li class="listitem"><p>
 109 Additionally, if a query usually requires an implicit conversion for a function, and
 110 if then the user defines a new function with the correct argument types, the parser
 111 should use this new function and no longer do implicit conversion to use the old function.
 112 </p></li></ul></div><p>
 113 </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="typeconv.html" title="Chapter 10. Type Conversion">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="typeconv.html" title="Chapter 10. Type Conversion">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="typeconv-oper.html" title="10.2. Operators">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 10. Type Conversion </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 10.2. Operators</td></tr></table></div></body></html>