2010-09-20 22:08:53 +02:00
|
|
|
<!-- doc/src/sgml/typeconv.sgml -->
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2011-04-05 20:06:06 +02:00
|
|
|
<chapter id="typeconv">
|
1998-07-08 15:53:15 +02:00
|
|
|
<title>Type Conversion</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="typeconv">
|
|
|
|
<primary>data type</primary>
|
|
|
|
<secondary>conversion</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
<acronym>SQL</acronym> statements can, intentionally or not, require
|
2009-04-27 18:27:36 +02:00
|
|
|
the mixing of different data types in the same expression.
|
2001-09-15 02:48:59 +02:00
|
|
|
<productname>PostgreSQL</productname> has extensive facilities for
|
1998-07-08 15:53:15 +02:00
|
|
|
evaluating mixed-type expressions.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
In many cases a user does not need
|
1998-07-08 15:53:15 +02:00
|
|
|
to understand the details of the type conversion mechanism.
|
2009-04-27 18:27:36 +02:00
|
|
|
However, implicit conversions done by <productname>PostgreSQL</productname>
|
2000-12-17 06:55:26 +01:00
|
|
|
can affect the results of a query. When necessary, these results
|
2004-12-24 00:07:38 +01:00
|
|
|
can be tailored by using <emphasis>explicit</emphasis> type conversion.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2001-09-15 02:48:59 +02:00
|
|
|
This chapter introduces the <productname>PostgreSQL</productname>
|
2000-12-17 06:55:26 +01:00
|
|
|
type conversion mechanisms and conventions.
|
2001-10-15 03:00:59 +02:00
|
|
|
Refer to the relevant sections in <xref linkend="datatype"> and <xref linkend="functions">
|
2000-12-17 06:55:26 +01:00
|
|
|
for more information on specific data types and allowed functions and
|
|
|
|
operators.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="typeconv-overview">
|
1998-07-08 15:53:15 +02:00
|
|
|
<title>Overview</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<acronym>SQL</acronym> is a strongly typed language. That is, every data item
|
|
|
|
has an associated data type which determines its behavior and allowed usage.
|
2001-09-15 02:48:59 +02:00
|
|
|
<productname>PostgreSQL</productname> has an extensible type system that is
|
2009-04-27 18:27:36 +02:00
|
|
|
more general and flexible than other <acronym>SQL</acronym> implementations.
|
2001-09-15 02:48:59 +02:00
|
|
|
Hence, most type conversion behavior in <productname>PostgreSQL</productname>
|
2004-12-24 00:07:38 +01:00
|
|
|
is governed by general rules rather than by <foreignphrase>ad hoc</>
|
2009-04-27 18:27:36 +02:00
|
|
|
heuristics. This allows the use of mixed-type expressions even with
|
|
|
|
user-defined types.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2004-12-24 00:07:38 +01:00
|
|
|
The <productname>PostgreSQL</productname> scanner/parser divides lexical
|
2009-04-27 18:27:36 +02:00
|
|
|
elements into five fundamental categories: integers, non-integer numbers,
|
2004-12-24 00:07:38 +01:00
|
|
|
strings, identifiers, and key words. Constants of most non-numeric types are
|
|
|
|
first classified as strings. The <acronym>SQL</acronym> language definition
|
|
|
|
allows specifying type names with strings, and this mechanism can be used in
|
2001-09-15 02:48:59 +02:00
|
|
|
<productname>PostgreSQL</productname> to start the parser down the correct
|
2009-04-27 18:27:36 +02:00
|
|
|
path. For example, the query:
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT text 'Origin' AS "label", point '(0,0)' AS "value";
|
|
|
|
|
|
|
|
label | value
|
2000-03-26 20:32:30 +02:00
|
|
|
--------+-------
|
|
|
|
Origin | (0,0)
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-10-15 03:00:59 +02:00
|
|
|
has two literal constants, of type <type>text</type> and <type>point</type>.
|
|
|
|
If a type is not specified for a string literal, then the placeholder type
|
2003-03-13 02:30:29 +01:00
|
|
|
<type>unknown</type> is assigned initially, to be resolved in later
|
2000-12-17 06:55:26 +01:00
|
|
|
stages as described below.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
There are four fundamental <acronym>SQL</acronym> constructs requiring
|
2001-09-15 02:48:59 +02:00
|
|
|
distinct type conversion rules in the <productname>PostgreSQL</productname>
|
1998-07-08 15:53:15 +02:00
|
|
|
parser:
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>
|
2004-12-24 00:07:38 +01:00
|
|
|
Function calls
|
1998-07-08 15:53:15 +02:00
|
|
|
</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2004-12-24 00:07:38 +01:00
|
|
|
Much of the <productname>PostgreSQL</productname> type system is built around a
|
|
|
|
rich set of functions. Functions can have one or more arguments.
|
|
|
|
Since <productname>PostgreSQL</productname> permits function
|
|
|
|
overloading, the function name alone does not uniquely identify the function
|
|
|
|
to be called; the parser must select the right function based on the data
|
|
|
|
types of the supplied arguments.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
|
|
<term>
|
2004-12-24 00:07:38 +01:00
|
|
|
Operators
|
1998-07-08 15:53:15 +02:00
|
|
|
</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2004-12-24 00:07:38 +01:00
|
|
|
<productname>PostgreSQL</productname> allows expressions with
|
|
|
|
prefix and postfix unary (one-argument) operators,
|
|
|
|
as well as binary (two-argument) operators. Like functions, operators can
|
2009-04-27 18:27:36 +02:00
|
|
|
be overloaded, so the same problem of selecting the right operator
|
2004-12-24 00:07:38 +01:00
|
|
|
exists.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
|
|
<term>
|
2003-03-13 02:30:29 +01:00
|
|
|
Value Storage
|
1998-07-08 15:53:15 +02:00
|
|
|
</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2001-09-15 02:48:59 +02:00
|
|
|
<acronym>SQL</acronym> <command>INSERT</command> and <command>UPDATE</command> statements place the results of
|
2003-03-13 02:30:29 +01:00
|
|
|
expressions into a table. The expressions in the statement must be matched up
|
2000-12-17 06:55:26 +01:00
|
|
|
with, and perhaps converted to, the types of the target columns.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
|
|
<term>
|
2005-06-27 00:05:42 +02:00
|
|
|
<literal>UNION</literal>, <literal>CASE</literal>, and related constructs
|
1998-07-08 15:53:15 +02:00
|
|
|
</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-12-14 01:10:32 +01:00
|
|
|
Since all query results from a unionized <command>SELECT</command> statement
|
2003-08-15 01:13:27 +02:00
|
|
|
must appear in a single set of columns, the types of the results of each
|
2003-12-14 01:10:32 +01:00
|
|
|
<command>SELECT</> clause must be matched up and converted to a uniform set.
|
2004-12-24 00:07:38 +01:00
|
|
|
Similarly, the result expressions of a <literal>CASE</> construct must be
|
2003-08-15 01:13:27 +02:00
|
|
|
converted to a common type so that the <literal>CASE</> expression as a whole
|
2005-06-27 00:05:42 +02:00
|
|
|
has a known output type. The same holds for <literal>ARRAY</> constructs,
|
|
|
|
and for the <function>GREATEST</> and <function>LEAST</> functions.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
The system catalogs store information about which conversions, or
|
|
|
|
<firstterm>casts</firstterm>, exist between which data types, and how to
|
2002-11-11 21:14:04 +01:00
|
|
|
perform those conversions. Additional casts can be added by the user
|
2010-04-03 09:23:02 +02:00
|
|
|
with the <xref linkend="sql-createcast">
|
2007-06-05 23:31:09 +02:00
|
|
|
command. (This is usually
|
2002-11-11 21:14:04 +01:00
|
|
|
done in conjunction with defining new data types. The set of casts
|
2009-04-27 18:27:36 +02:00
|
|
|
between built-in types has been carefully crafted and is best not
|
2003-05-26 02:11:29 +02:00
|
|
|
altered.)
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>data type</primary>
|
|
|
|
<secondary>category</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
An additional heuristic provided by the parser allows improved determination
|
|
|
|
of the proper casting behavior among groups of types that have implicit casts.
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
Data types are divided into several basic <firstterm>type
|
|
|
|
categories</firstterm>, including <type>boolean</type>, <type>numeric</type>,
|
|
|
|
<type>string</type>, <type>bitstring</type>, <type>datetime</type>,
|
|
|
|
<type>timespan</type>, <type>geometric</type>, <type>network</type>, and
|
|
|
|
user-defined. (For a list see <xref linkend="catalog-typcategory-table">;
|
|
|
|
but note it is also possible to create custom type categories.) Within each
|
2008-07-30 21:35:13 +02:00
|
|
|
category there can be one or more <firstterm>preferred types</firstterm>, which
|
2009-06-17 23:58:49 +02:00
|
|
|
are preferred when there is a choice of possible types. With careful selection
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
of preferred types and available implicit casts, it is possible to ensure that
|
|
|
|
ambiguous expressions (those with multiple candidate parsing solutions) can be
|
|
|
|
resolved in a useful way.
|
|
|
|
</para>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<para>
|
|
|
|
All type conversion rules are designed with several principles in mind:
|
|
|
|
|
2002-11-11 21:14:04 +01:00
|
|
|
<itemizedlist>
|
1998-07-08 15:53:15 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2000-03-20 05:22:11 +01:00
|
|
|
Implicit conversions should never have surprising or unpredictable outcomes.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
There should be no extra overhead in the parser or executor
|
1998-07-08 15:53:15 +02:00
|
|
|
if a query does not need implicit type conversion.
|
2009-04-27 18:27:36 +02:00
|
|
|
That is, if a query is well-formed and the types already match, then the query should execute
|
1998-07-08 15:53:15 +02:00
|
|
|
without spending extra time in the parser and without introducing unnecessary implicit conversion
|
2009-04-27 18:27:36 +02:00
|
|
|
calls in the query.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Additionally, if a query usually requires an implicit conversion for a function, and
|
2003-03-13 02:30:29 +01:00
|
|
|
if then the user defines a new function with the correct argument types, the parser
|
2009-06-17 23:58:49 +02:00
|
|
|
should use this new function and no longer do implicit conversion to use the old function.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
1998-07-08 15:53:15 +02:00
|
|
|
</itemizedlist>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
|
1998-12-29 03:24:47 +01:00
|
|
|
</sect1>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="typeconv-oper">
|
1998-07-08 15:53:15 +02:00
|
|
|
<title>Operators</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="typeconv-oper">
|
|
|
|
<primary>operator</primary>
|
|
|
|
<secondary>type resolution in an invocation</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
The specific operator that is referenced by an operator expression
|
|
|
|
is determined using the following procedure.
|
|
|
|
Note that this procedure is indirectly affected
|
|
|
|
by the precedence of the involved operators, since that will determine
|
|
|
|
which sub-expressions are taken to be the inputs of which operators.
|
|
|
|
See <xref linkend="sql-precedence"> for more information.
|
2001-09-15 02:48:59 +02:00
|
|
|
</para>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<procedure>
|
2003-05-26 02:11:29 +02:00
|
|
|
<title>Operator Type Resolution</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2002-04-25 22:14:43 +02:00
|
|
|
Select the operators to be considered from the
|
2009-04-27 18:27:36 +02:00
|
|
|
<classname>pg_operator</classname> system catalog. If a non-schema-qualified
|
2003-03-13 02:30:29 +01:00
|
|
|
operator name was used (the usual case), the operators
|
2009-06-17 23:58:49 +02:00
|
|
|
considered are those with the matching name and argument count that are
|
2002-09-13 00:05:36 +02:00
|
|
|
visible in the current search path (see <xref linkend="ddl-schemas-path">).
|
2002-04-25 22:14:43 +02:00
|
|
|
If a qualified operator name was given, only operators in the specified
|
|
|
|
schema are considered.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<substeps>
|
|
|
|
<step performance="optional">
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
If the search path finds multiple operators with identical argument types,
|
|
|
|
only the one appearing earliest in the path is considered. Operators with
|
2002-04-25 22:14:43 +02:00
|
|
|
different argument types are considered on an equal footing regardless of
|
|
|
|
search path position.
|
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
</substeps>
|
|
|
|
</step>
|
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
Check for an operator accepting exactly the input argument types.
|
|
|
|
If one exists (there can be only one exact match in the set of
|
|
|
|
operators considered), use it.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<substeps>
|
|
|
|
<step performance="optional">
|
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
If one argument of a binary operator invocation is of the <type>unknown</type> type,
|
2000-12-17 06:55:26 +01:00
|
|
|
then assume it is the same type as the other argument for this check.
|
2009-06-17 23:58:49 +02:00
|
|
|
Invocations involving two <type>unknown</type> inputs, or a unary operator
|
|
|
|
with an <type>unknown</type> input, will never find a match at this step.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
</substeps>
|
1998-12-29 03:24:47 +01:00
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
Look for the best match.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
<substeps>
|
2000-12-17 06:55:26 +01:00
|
|
|
<step performance="required">
|
1998-07-08 15:53:15 +02:00
|
|
|
<para>
|
2002-04-25 22:14:43 +02:00
|
|
|
Discard candidate operators for which the input types do not match
|
2003-03-13 02:30:29 +01:00
|
|
|
and cannot be converted (using an implicit conversion) to match.
|
2002-04-25 22:14:43 +02:00
|
|
|
<type>unknown</type> literals are
|
2003-03-13 02:30:29 +01:00
|
|
|
assumed to be convertible to anything for this purpose. If only one
|
2002-04-25 22:14:43 +02:00
|
|
|
candidate remains, use it; else continue to the next step.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2000-12-17 06:55:26 +01:00
|
|
|
Run through all candidates and keep those with the most exact matches
|
2003-11-12 23:47:47 +01:00
|
|
|
on input types. (Domains are considered the same as their base type
|
2009-04-27 18:27:36 +02:00
|
|
|
for this purpose.) Keep all candidates if none have exact matches.
|
2000-12-17 06:55:26 +01:00
|
|
|
If only one candidate remains, use it; else continue to the next step.
|
|
|
|
</para>
|
2000-12-17 18:50:46 +01:00
|
|
|
</step>
|
2000-12-17 06:55:26 +01:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2003-05-26 02:11:29 +02:00
|
|
|
Run through all candidates and keep those that accept preferred types (of the
|
2003-11-01 02:56:29 +01:00
|
|
|
input data type's type category) at the most positions where type conversion
|
2003-05-26 02:11:29 +02:00
|
|
|
will be required.
|
2000-12-17 06:55:26 +01:00
|
|
|
Keep all candidates if none accept preferred types.
|
|
|
|
If only one candidate remains, use it; else continue to the next step.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
If any input arguments are <type>unknown</type>, check the type
|
2001-10-13 01:32:34 +02:00
|
|
|
categories accepted at those argument positions by the remaining
|
2003-05-26 02:11:29 +02:00
|
|
|
candidates. At each position, select the <type>string</type> category
|
|
|
|
if any
|
2003-03-13 02:30:29 +01:00
|
|
|
candidate accepts that category. (This bias towards string is appropriate
|
2009-04-27 18:27:36 +02:00
|
|
|
since an unknown-type literal looks like a string.) Otherwise, if
|
2001-10-13 01:32:34 +02:00
|
|
|
all the remaining candidates accept the same type category, select that
|
|
|
|
category; otherwise fail because the correct choice cannot be deduced
|
2003-05-26 02:11:29 +02:00
|
|
|
without more clues. Now discard
|
2003-03-13 02:30:29 +01:00
|
|
|
candidates that do not accept the selected type category. Furthermore,
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
if any candidate accepts a preferred type in that category,
|
2001-10-13 01:32:34 +02:00
|
|
|
discard candidates that accept non-preferred types for that argument.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2000-12-17 06:55:26 +01:00
|
|
|
If only one candidate remains, use it. If no candidate or more than one
|
|
|
|
candidate remains,
|
2000-12-19 01:54:59 +01:00
|
|
|
then fail.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
</substeps>
|
1998-12-29 03:24:47 +01:00
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
</procedure>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<para>
|
|
|
|
Some examples follow.
|
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
2007-06-05 23:31:09 +02:00
|
|
|
<title>Factorial Operator Type Resolution</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2007-06-05 23:31:09 +02:00
|
|
|
There is only one factorial operator (postfix <literal>!</>)
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
defined in the standard catalog, and it takes an argument of type
|
2007-06-05 23:31:09 +02:00
|
|
|
<type>bigint</type>.
|
|
|
|
The scanner assigns an initial type of <type>integer</type> to the argument
|
|
|
|
in this query expression:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2007-06-05 23:31:09 +02:00
|
|
|
SELECT 40 ! AS "40 factorial";
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2007-06-05 23:31:09 +02:00
|
|
|
40 factorial
|
|
|
|
--------------------------------------------------
|
|
|
|
815915283247897734345611269596115894272000000000
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2007-06-05 23:31:09 +02:00
|
|
|
So the parser does a type conversion on the operand and the query
|
2009-04-27 18:27:36 +02:00
|
|
|
is equivalent to:
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2007-06-05 23:31:09 +02:00
|
|
|
SELECT CAST(40 AS bigint) ! AS "40 factorial";
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
|
|
|
<title>String Concatenation Operator Type Resolution</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
A string-like syntax is used for working with string types and for
|
2003-03-13 02:30:29 +01:00
|
|
|
working with complex extension types.
|
1998-07-08 15:53:15 +02:00
|
|
|
Strings with unspecified type are matched with likely operator candidates.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2001-10-15 03:00:59 +02:00
|
|
|
An example with one unspecified argument:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT text 'abc' || 'def' AS "text and unknown";
|
|
|
|
|
|
|
|
text and unknown
|
2000-03-26 20:32:30 +02:00
|
|
|
------------------
|
|
|
|
abcdef
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
In this case the parser looks to see if there is an operator taking <type>text</type>
|
|
|
|
for both arguments. Since there is, it assumes that the second argument should
|
2009-04-27 18:27:36 +02:00
|
|
|
be interpreted as type <type>text</type>.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
Here is a concatenation on unspecified types:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT 'abc' || 'def' AS "unspecified";
|
|
|
|
|
|
|
|
unspecified
|
2000-03-26 20:32:30 +02:00
|
|
|
-------------
|
|
|
|
abcdef
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
In this case there is no initial hint for which type to use, since no types
|
|
|
|
are specified in the query. So, the parser looks for all candidate operators
|
2000-12-17 06:55:26 +01:00
|
|
|
and finds that there are candidates accepting both string-category and
|
2001-09-09 19:21:59 +02:00
|
|
|
bit-string-category inputs. Since string category is preferred when available,
|
2009-06-17 23:58:49 +02:00
|
|
|
that category is selected, and then the
|
2003-03-13 02:30:29 +01:00
|
|
|
preferred type for strings, <type>text</type>, is used as the specific
|
2009-06-17 23:58:49 +02:00
|
|
|
type to resolve the unknown literals as.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2003-03-20 17:17:32 +01:00
|
|
|
<example>
|
2003-12-02 01:26:59 +01:00
|
|
|
<title>Absolute-Value and Negation Operator Type Resolution</title>
|
2003-03-20 17:17:32 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
The <productname>PostgreSQL</productname> operator catalog has several
|
|
|
|
entries for the prefix operator <literal>@</>, all of which implement
|
|
|
|
absolute-value operations for various numeric data types. One of these
|
|
|
|
entries is for type <type>float8</type>, which is the preferred type in
|
|
|
|
the numeric category. Therefore, <productname>PostgreSQL</productname>
|
2007-06-05 23:31:09 +02:00
|
|
|
will use that entry when faced with an <type>unknown</> input:
|
2003-03-20 17:17:32 +01:00
|
|
|
<screen>
|
|
|
|
SELECT @ '-4.5' AS "abs";
|
|
|
|
abs
|
|
|
|
-----
|
|
|
|
4.5
|
|
|
|
(1 row)
|
|
|
|
</screen>
|
2007-06-05 23:31:09 +02:00
|
|
|
Here the system has implicitly resolved the unknown-type literal as type
|
|
|
|
<type>float8</type> before applying the chosen operator. We can verify that
|
|
|
|
<type>float8</type> and not some other type was used:
|
2003-03-20 17:17:32 +01:00
|
|
|
<screen>
|
|
|
|
SELECT @ '-4.5e500' AS "abs";
|
|
|
|
|
2003-09-30 05:22:33 +02:00
|
|
|
ERROR: "-4.5e500" is out of range for type double precision
|
2003-03-20 17:17:32 +01:00
|
|
|
</screen>
|
|
|
|
</para>
|
2003-12-02 01:26:59 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
On the other hand, the prefix operator <literal>~</> (bitwise negation)
|
|
|
|
is defined only for integer data types, not for <type>float8</type>. So, if we
|
|
|
|
try a similar case with <literal>~</>, we get:
|
|
|
|
<screen>
|
|
|
|
SELECT ~ '20' AS "negation";
|
|
|
|
|
|
|
|
ERROR: operator is not unique: ~ "unknown"
|
2007-06-05 23:31:09 +02:00
|
|
|
HINT: Could not choose a best candidate operator. You might need to add
|
|
|
|
explicit type casts.
|
2003-12-02 01:26:59 +01:00
|
|
|
</screen>
|
Wording cleanup for error messages. Also change can't -> cannot.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 20:10:30 +01:00
|
|
|
This happens because the system cannot decide which of the several
|
2003-12-02 01:26:59 +01:00
|
|
|
possible <literal>~</> operators should be preferred. We can help
|
|
|
|
it out with an explicit cast:
|
|
|
|
<screen>
|
|
|
|
SELECT ~ CAST('20' AS int8) AS "negation";
|
|
|
|
|
|
|
|
negation
|
|
|
|
----------
|
|
|
|
-21
|
|
|
|
(1 row)
|
|
|
|
</screen>
|
|
|
|
</para>
|
2003-03-20 17:17:32 +01:00
|
|
|
</example>
|
|
|
|
|
1998-12-29 03:24:47 +01:00
|
|
|
</sect1>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="typeconv-func">
|
1998-07-08 15:53:15 +02:00
|
|
|
<title>Functions</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="typeconv-func">
|
|
|
|
<primary>function</primary>
|
|
|
|
<secondary>type resolution in an invocation</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
The specific function that is referenced by a function call
|
|
|
|
is determined using the following procedure.
|
2001-09-15 02:48:59 +02:00
|
|
|
</para>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<procedure>
|
2003-05-26 02:11:29 +02:00
|
|
|
<title>Function Type Resolution</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2002-04-25 22:14:43 +02:00
|
|
|
Select the functions to be considered from the
|
2009-04-27 18:27:36 +02:00
|
|
|
<classname>pg_proc</classname> system catalog. If a non-schema-qualified
|
2003-03-13 02:30:29 +01:00
|
|
|
function name was used, the functions
|
2009-06-17 23:58:49 +02:00
|
|
|
considered are those with the matching name and argument count that are
|
2002-09-13 00:05:36 +02:00
|
|
|
visible in the current search path (see <xref linkend="ddl-schemas-path">).
|
2002-04-25 22:14:43 +02:00
|
|
|
If a qualified function name was given, only functions in the specified
|
|
|
|
schema are considered.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<substeps>
|
|
|
|
<step performance="optional">
|
|
|
|
<para>
|
|
|
|
If the search path finds multiple functions of identical argument types,
|
2009-04-27 18:27:36 +02:00
|
|
|
only the one appearing earliest in the path is considered. Functions of
|
2002-04-25 22:14:43 +02:00
|
|
|
different argument types are considered on an equal footing regardless of
|
|
|
|
search path position.
|
|
|
|
</para>
|
|
|
|
</step>
|
2008-07-16 03:30:23 +02:00
|
|
|
<step performance="optional">
|
|
|
|
<para>
|
|
|
|
If a function is declared with a <literal>VARIADIC</> array parameter, and
|
|
|
|
the call does not use the <literal>VARIADIC</> keyword, then the function
|
|
|
|
is treated as if the array parameter were replaced by one or more occurrences
|
|
|
|
of its element type, as needed to match the call. After such expansion the
|
|
|
|
function might have effective argument types identical to some non-variadic
|
|
|
|
function. In that case the function appearing earlier in the search path is
|
|
|
|
used, or if the two functions are in the same schema, the non-variadic one is
|
2008-12-18 19:20:35 +01:00
|
|
|
preferred.
|
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
<step performance="optional">
|
|
|
|
<para>
|
|
|
|
Functions that have default values for parameters are considered to match any
|
|
|
|
call that omits zero or more of the defaultable parameter positions. If more
|
|
|
|
than one such function matches a call, the one appearing earliest in the
|
|
|
|
search path is used. If there are two or more such functions in the same
|
|
|
|
schema with identical parameter types in the non-defaulted positions (which is
|
|
|
|
possible if they have different sets of defaultable parameters), the system
|
|
|
|
will not be able to determine which to prefer, and so an <quote>ambiguous
|
|
|
|
function call</> error will result if no better match to the call can be
|
|
|
|
found.
|
2008-07-16 03:30:23 +02:00
|
|
|
</para>
|
|
|
|
</step>
|
2002-04-25 22:14:43 +02:00
|
|
|
</substeps>
|
|
|
|
</step>
|
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
Check for a function accepting exactly the input argument types.
|
|
|
|
If one exists (there can be only one exact match in the set of
|
|
|
|
functions considered), use it.
|
2000-12-17 06:55:26 +01:00
|
|
|
(Cases involving <type>unknown</type> will never find a match at
|
|
|
|
this step.)
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
If no exact match is found, see if the function call appears
|
2007-06-05 23:31:09 +02:00
|
|
|
to be a special type conversion request. This happens if the function call
|
2001-10-05 00:06:46 +02:00
|
|
|
has just one argument and the function name is the same as the (internal)
|
|
|
|
name of some data type. Furthermore, the function argument must be either
|
2008-07-11 09:02:43 +02:00
|
|
|
an unknown-type literal, or a type that is binary-coercible to the named
|
2007-06-05 23:31:09 +02:00
|
|
|
data type, or a type that could be converted to the named data type by
|
|
|
|
applying that type's I/O functions (that is, the conversion is either to or
|
|
|
|
from one of the standard string types). When these conditions are met,
|
|
|
|
the function call is treated as a form of <literal>CAST</> specification.
|
|
|
|
<footnote>
|
|
|
|
<para>
|
|
|
|
The reason for this step is to support function-style cast specifications
|
|
|
|
in cases where there is not an actual cast function. If there is a cast
|
|
|
|
function, it is conventionally named after its output type, and so there
|
|
|
|
is no need to have a special case. See
|
2010-04-03 09:23:02 +02:00
|
|
|
<xref linkend="sql-createcast">
|
2007-06-05 23:31:09 +02:00
|
|
|
for additional commentary.
|
|
|
|
</para>
|
|
|
|
</footnote>
|
2001-10-05 00:06:46 +02:00
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
1998-07-08 15:53:15 +02:00
|
|
|
Look for the best match.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
<substeps>
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
Discard candidate functions for which the input types do not match
|
2003-03-13 02:30:29 +01:00
|
|
|
and cannot be converted (using an implicit conversion) to match.
|
2002-04-25 22:14:43 +02:00
|
|
|
<type>unknown</type> literals are
|
2003-03-13 02:30:29 +01:00
|
|
|
assumed to be convertible to anything for this purpose. If only one
|
2002-04-25 22:14:43 +02:00
|
|
|
candidate remains, use it; else continue to the next step.
|
2000-12-17 06:55:26 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2000-12-17 06:55:26 +01:00
|
|
|
Run through all candidates and keep those with the most exact matches
|
2003-11-12 23:47:47 +01:00
|
|
|
on input types. (Domains are considered the same as their base type
|
2009-04-27 18:27:36 +02:00
|
|
|
for this purpose.) Keep all candidates if none have exact matches.
|
2000-12-17 06:55:26 +01:00
|
|
|
If only one candidate remains, use it; else continue to the next step.
|
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2003-05-26 02:11:29 +02:00
|
|
|
Run through all candidates and keep those that accept preferred types (of the
|
2003-11-01 02:56:29 +01:00
|
|
|
input data type's type category) at the most positions where type conversion
|
2003-05-26 02:11:29 +02:00
|
|
|
will be required.
|
2000-12-17 06:55:26 +01:00
|
|
|
Keep all candidates if none accept preferred types.
|
|
|
|
If only one candidate remains, use it; else continue to the next step.
|
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2003-05-26 02:11:29 +02:00
|
|
|
If any input arguments are <type>unknown</type>, check the type categories
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
accepted
|
2000-12-17 06:55:26 +01:00
|
|
|
at those argument positions by the remaining candidates. At each position,
|
2003-03-13 02:30:29 +01:00
|
|
|
select the <type>string</type> category if any candidate accepts that category.
|
|
|
|
(This bias towards string
|
2009-04-27 18:27:36 +02:00
|
|
|
is appropriate since an unknown-type literal looks like a string.)
|
2000-12-17 06:55:26 +01:00
|
|
|
Otherwise, if all the remaining candidates accept the same type category,
|
2000-12-19 01:54:59 +01:00
|
|
|
select that category; otherwise fail because
|
2003-03-13 02:30:29 +01:00
|
|
|
the correct choice cannot be deduced without more clues.
|
2003-05-26 02:11:29 +02:00
|
|
|
Now discard candidates that do not accept the selected type category.
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
Furthermore, if any candidate accepts a preferred type in that category,
|
|
|
|
discard candidates that accept non-preferred types for that argument.
|
2000-12-17 06:55:26 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
If only one candidate remains, use it. If no candidate or more than one
|
|
|
|
candidate remains,
|
2000-12-19 01:54:59 +01:00
|
|
|
then fail.
|
2000-12-17 06:55:26 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
</substeps>
|
1998-12-29 03:24:47 +01:00
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
</procedure>
|
2000-12-17 06:55:26 +01:00
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<para>
|
2003-05-26 02:11:29 +02:00
|
|
|
Note that the <quote>best match</> rules are identical for operator and
|
|
|
|
function type resolution.
|
2003-03-13 02:30:29 +01:00
|
|
|
Some examples follow.
|
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Rounding Function Argument Type Resolution</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
There is only one <function>round</function> function that takes two
|
|
|
|
arguments; it takes a first argument of type <type>numeric</type> and
|
|
|
|
a second argument of type <type>integer</type>.
|
|
|
|
So the following query automatically converts
|
2003-03-13 02:30:29 +01:00
|
|
|
the first argument of type <type>integer</type> to
|
|
|
|
<type>numeric</type>:
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT round(4, 4);
|
|
|
|
|
|
|
|
round
|
|
|
|
--------
|
|
|
|
4.0000
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2009-04-27 18:27:36 +02:00
|
|
|
That query is actually transformed by the parser to:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT round(CAST (4 AS numeric), 4);
|
|
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Since numeric constants with decimal points are initially assigned the
|
|
|
|
type <type>numeric</type>, the following query will require no type
|
2009-04-27 18:27:36 +02:00
|
|
|
conversion and therefore might be slightly more efficient:
|
2003-03-13 02:30:29 +01:00
|
|
|
<screen>
|
|
|
|
SELECT round(4.0, 4);
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
|
|
|
<title>Substring Function Type Resolution</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
There are several <function>substr</function> functions, one of which
|
|
|
|
takes types <type>text</type> and <type>integer</type>. If called
|
|
|
|
with a string constant of unspecified type, the system chooses the
|
|
|
|
candidate function that accepts an argument of the preferred category
|
|
|
|
<literal>string</literal> (namely of type <type>text</type>).
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT substr('1234', 3);
|
|
|
|
|
2000-03-26 20:32:30 +02:00
|
|
|
substr
|
|
|
|
--------
|
|
|
|
34
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
If the string is declared to be of type <type>varchar</type>, as might be the case
|
2003-03-13 02:30:29 +01:00
|
|
|
if it comes from a table, then the parser will try to convert it to become <type>text</type>:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT substr(varchar '1234', 3);
|
|
|
|
|
2000-03-26 20:32:30 +02:00
|
|
|
substr
|
|
|
|
--------
|
|
|
|
34
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2009-04-27 18:27:36 +02:00
|
|
|
This is transformed by the parser to effectively become:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT substr(CAST (varchar '1234' AS text), 3);
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
<para>
|
1998-07-08 15:53:15 +02:00
|
|
|
<note>
|
|
|
|
<para>
|
2003-05-26 02:11:29 +02:00
|
|
|
The parser learns from the <structname>pg_cast</> catalog that
|
|
|
|
<type>text</type> and <type>varchar</type>
|
2003-03-13 02:30:29 +01:00
|
|
|
are binary-compatible, meaning that one can be passed to a function that
|
2000-12-17 06:55:26 +01:00
|
|
|
accepts the other without doing any physical conversion. Therefore, no
|
2007-06-05 23:31:09 +02:00
|
|
|
type conversion call is really inserted in this case.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
</note>
|
2001-09-15 02:48:59 +02:00
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2007-06-05 23:31:09 +02:00
|
|
|
And, if the function is called with an argument of type <type>integer</type>,
|
|
|
|
the parser will try to convert that to <type>text</type>:
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT substr(1234, 3);
|
2007-06-05 23:31:09 +02:00
|
|
|
ERROR: function substr(integer, integer) does not exist
|
|
|
|
HINT: No function matches the given name and argument types. You might need
|
|
|
|
to add explicit type casts.
|
|
|
|
</screen>
|
|
|
|
|
|
|
|
This does not work because <type>integer</> does not have an implicit cast
|
|
|
|
to <type>text</>. An explicit cast will work, however:
|
|
|
|
<screen>
|
|
|
|
SELECT substr(CAST (1234 AS text), 3);
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2000-03-26 20:32:30 +02:00
|
|
|
substr
|
|
|
|
--------
|
|
|
|
34
|
1998-07-08 15:53:15 +02:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
|
|
|
|
1998-12-29 03:24:47 +01:00
|
|
|
</sect1>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="typeconv-query">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Value Storage</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-10-15 03:00:59 +02:00
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
Values to be inserted into a table are converted to the destination
|
2002-01-20 23:19:57 +01:00
|
|
|
column's data type according to the
|
2001-10-15 03:00:59 +02:00
|
|
|
following steps.
|
|
|
|
</para>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<procedure>
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Value Storage Type Conversion</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
Check for an exact match with the target.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
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
|
2000-12-17 06:55:26 +01:00
|
|
|
the literal string will be fed to the input conversion routine for the target
|
|
|
|
type.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2004-12-24 00:07:38 +01:00
|
|
|
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
|
|
|
|
<structname>pg_cast</> 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 <type>integer</type>, which receives
|
2011-09-06 18:14:51 +02:00
|
|
|
the destination column's <structfield>atttypmod</> value (typically its
|
|
|
|
declared length, although the interpretation of <structfield>atttypmod</>
|
|
|
|
varies for different data types), and it may take a third <type>boolean</>
|
|
|
|
parameter that says whether the cast is explicit or implicit. The cast
|
|
|
|
function
|
2004-12-24 00:07:38 +01:00
|
|
|
is responsible for applying any length-dependent semantics such as size
|
|
|
|
checking or truncation.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
</procedure>
|
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
2001-10-15 03:00:59 +02:00
|
|
|
<title><type>character</type> Storage Type Conversion</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2011-09-06 18:14:51 +02:00
|
|
|
For a target column declared as <type>character(20)</type> the following
|
|
|
|
statement shows that the stored value is sized correctly:
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
CREATE TABLE vv (v character(20));
|
|
|
|
INSERT INTO vv SELECT 'abc' || 'def';
|
2011-09-06 18:14:51 +02:00
|
|
|
SELECT v, octet_length(v) FROM vv;
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2011-09-06 18:14:51 +02:00
|
|
|
v | octet_length
|
|
|
|
----------------------+--------------
|
|
|
|
abcdef | 20
|
2000-12-17 06:55:26 +01:00
|
|
|
(1 row)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
2000-12-17 06:55:26 +01:00
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<para>
|
2001-09-15 02:48:59 +02:00
|
|
|
What has really happened here is that the two unknown literals are resolved
|
2001-10-15 03:00:59 +02:00
|
|
|
to <type>text</type> by default, allowing the <literal>||</literal> operator
|
|
|
|
to be resolved as <type>text</type> concatenation. Then the <type>text</type>
|
2003-03-13 02:30:29 +01:00
|
|
|
result of the operator is converted to <type>bpchar</type> (<quote>blank-padded
|
|
|
|
char</>, the internal name of the <type>character</type> data type) to match the target
|
2008-07-11 09:02:43 +02:00
|
|
|
column type. (Since the conversion from <type>text</type> to
|
|
|
|
<type>bpchar</type> is binary-coercible, this conversion does
|
2001-10-15 03:00:59 +02:00
|
|
|
not insert any real function call.) Finally, the sizing function
|
2011-09-06 18:14:51 +02:00
|
|
|
<literal>bpchar(bpchar, integer, boolean)</> is found in the system catalog
|
2001-10-15 03:00:59 +02:00
|
|
|
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.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
1998-12-29 03:24:47 +01:00
|
|
|
</sect1>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2000-12-17 06:55:26 +01:00
|
|
|
<sect1 id="typeconv-union-case">
|
2005-06-27 00:05:42 +02:00
|
|
|
<title><literal>UNION</literal>, <literal>CASE</literal>, and Related Constructs</title>
|
2003-08-31 19:32:24 +02:00
|
|
|
|
|
|
|
<indexterm zone="typeconv-union-case">
|
|
|
|
<primary>UNION</primary>
|
|
|
|
<secondary>determination of result type</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm zone="typeconv-union-case">
|
|
|
|
<primary>CASE</primary>
|
|
|
|
<secondary>determination of result type</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm zone="typeconv-union-case">
|
|
|
|
<primary>ARRAY</primary>
|
|
|
|
<secondary>determination of result type</secondary>
|
|
|
|
</indexterm>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2006-09-18 21:54:01 +02:00
|
|
|
<indexterm zone="typeconv-union-case">
|
|
|
|
<primary>VALUES</primary>
|
|
|
|
<secondary>determination of result type</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2005-06-27 00:05:42 +02:00
|
|
|
<indexterm zone="typeconv-union-case">
|
|
|
|
<primary>GREATEST</primary>
|
|
|
|
<secondary>determination of result type</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm zone="typeconv-union-case">
|
|
|
|
<primary>LEAST</primary>
|
|
|
|
<secondary>determination of result type</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<para>
|
2003-11-04 10:55:39 +01:00
|
|
|
SQL <literal>UNION</> constructs must match up possibly dissimilar
|
|
|
|
types to become a single result set. The resolution algorithm is
|
|
|
|
applied separately to each output column of a union query. The
|
|
|
|
<literal>INTERSECT</> and <literal>EXCEPT</> constructs resolve
|
|
|
|
dissimilar types in the same way as <literal>UNION</>. The
|
2006-09-18 21:54:01 +02:00
|
|
|
<literal>CASE</>, <literal>ARRAY</>, <literal>VALUES</>,
|
|
|
|
<function>GREATEST</> and <function>LEAST</> constructs use the identical
|
2003-11-04 10:55:39 +01:00
|
|
|
algorithm to match up their component expressions and select a result
|
|
|
|
data type.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2003-03-13 02:30:29 +01:00
|
|
|
|
1998-07-08 15:53:15 +02:00
|
|
|
<procedure>
|
2005-06-27 00:05:42 +02:00
|
|
|
<title>Type Resolution for <literal>UNION</literal>, <literal>CASE</literal>,
|
|
|
|
and Related Constructs</title>
|
2000-12-17 06:55:26 +01:00
|
|
|
|
Fix select_common_type() so that it can select a domain type, if all inputs
to a UNION, CASE, or related construct are of the same domain type. The
main part of this routine smashes domains to their base types, which seems
necessary because the logic involves TypeCategory() and IsPreferredType(),
neither of which work usefully on domains. However, we can add a first
pass that just detects whether all the inputs are exactly the same type,
and if so accept that without question (so long as it's not UNKNOWN).
Per recent gripe from Dean Rasheed.
In passing, remove some tests for InvalidOid, which have clearly been dead
code for quite some time now, because getBaseType() would fail on that input.
Also, clarify the manual's not-very-precise description of the existing
algorithm's behavior.
2007-11-26 17:46:51 +01:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
If all inputs are of the same type, and it is not <type>unknown</type>,
|
|
|
|
resolve as that type. Otherwise, replace any domain types in the list with
|
|
|
|
their underlying base types.
|
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
|
2000-12-17 06:55:26 +01:00
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
If all inputs are of type <type>unknown</type>, resolve as type
|
2003-03-13 02:30:29 +01:00
|
|
|
<type>text</type> (the preferred type of the string category).
|
2009-04-27 18:27:36 +02:00
|
|
|
Otherwise, <type>unknown</type> inputs are ignored.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
2000-12-17 06:55:26 +01:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
2000-12-19 01:54:59 +01:00
|
|
|
If the non-unknown inputs are not all of the same type category, fail.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
Choose the first non-unknown input type which is a preferred type in
|
Fix select_common_type() so that it can select a domain type, if all inputs
to a UNION, CASE, or related construct are of the same domain type. The
main part of this routine smashes domains to their base types, which seems
necessary because the logic involves TypeCategory() and IsPreferredType(),
neither of which work usefully on domains. However, we can add a first
pass that just detects whether all the inputs are exactly the same type,
and if so accept that without question (so long as it's not UNKNOWN).
Per recent gripe from Dean Rasheed.
In passing, remove some tests for InvalidOid, which have clearly been dead
code for quite some time now, because getBaseType() would fail on that input.
Also, clarify the manual's not-very-precise description of the existing
algorithm's behavior.
2007-11-26 17:46:51 +01:00
|
|
|
that category, if there is one.
|
|
|
|
</para>
|
|
|
|
</step>
|
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
|
|
|
Otherwise, choose the last non-unknown input type that allows all the
|
|
|
|
preceding non-unknown inputs to be implicitly converted to it. (There
|
|
|
|
always is such a type, since at least the first type in the list must
|
|
|
|
satisfy this condition.)
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
2000-12-17 06:55:26 +01:00
|
|
|
|
|
|
|
<step performance="required">
|
|
|
|
<para>
|
Fix select_common_type() so that it can select a domain type, if all inputs
to a UNION, CASE, or related construct are of the same domain type. The
main part of this routine smashes domains to their base types, which seems
necessary because the logic involves TypeCategory() and IsPreferredType(),
neither of which work usefully on domains. However, we can add a first
pass that just detects whether all the inputs are exactly the same type,
and if so accept that without question (so long as it's not UNKNOWN).
Per recent gripe from Dean Rasheed.
In passing, remove some tests for InvalidOid, which have clearly been dead
code for quite some time now, because getBaseType() would fail on that input.
Also, clarify the manual's not-very-precise description of the existing
algorithm's behavior.
2007-11-26 17:46:51 +01:00
|
|
|
Convert all inputs to the selected type. Fail if there is not a
|
|
|
|
conversion from a given input to the selected type.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
</step>
|
1998-07-08 15:53:15 +02:00
|
|
|
</procedure>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<para>
|
|
|
|
Some examples follow.
|
|
|
|
</para>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Type Resolution with Underspecified Types in a Union</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT text 'a' AS "text" UNION SELECT 'b';
|
|
|
|
|
|
|
|
text
|
2000-03-26 20:32:30 +02:00
|
|
|
------
|
|
|
|
a
|
|
|
|
b
|
1998-07-08 15:53:15 +02:00
|
|
|
(2 rows)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
2009-04-27 18:27:36 +02:00
|
|
|
Here, the unknown-type literal <literal>'b'</literal> will be resolved to type <type>text</type>.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Type Resolution in a Simple Union</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT 1.2 AS "numeric" UNION SELECT 1;
|
|
|
|
|
|
|
|
numeric
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
---------
|
|
|
|
1
|
|
|
|
1.2
|
1998-07-08 15:53:15 +02:00
|
|
|
(2 rows)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
The literal <literal>1.2</> is of type <type>numeric</>,
|
2003-03-13 02:30:29 +01:00
|
|
|
and the <type>integer</type> value <literal>1</> can be cast implicitly to
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
<type>numeric</>, so that type is used.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
2001-09-15 02:48:59 +02:00
|
|
|
<example>
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Type Resolution in a Transposed Union</title>
|
1998-07-08 15:53:15 +02:00
|
|
|
|
|
|
|
<para>
|
2001-09-15 02:48:59 +02:00
|
|
|
<screen>
|
2003-03-13 02:30:29 +01:00
|
|
|
SELECT 1 AS "real" UNION SELECT CAST('2.2' AS REAL);
|
|
|
|
|
|
|
|
real
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
------
|
|
|
|
1
|
|
|
|
2.2
|
2000-12-17 06:55:26 +01:00
|
|
|
(2 rows)
|
2001-09-15 02:48:59 +02:00
|
|
|
</screen>
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
Here, since type <type>real</> cannot be implicitly cast to <type>integer</>,
|
|
|
|
but <type>integer</> can be implicitly cast to <type>real</>, the union
|
|
|
|
result type is resolved as <type>real</>.
|
1998-12-29 03:24:47 +01:00
|
|
|
</para>
|
2001-09-15 02:48:59 +02:00
|
|
|
</example>
|
|
|
|
|
1998-12-29 03:24:47 +01:00
|
|
|
</sect1>
|
1998-07-08 15:53:15 +02:00
|
|
|
</chapter>
|