From f45df8c0144005739d09387cb594baaaa08295a6 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 26 May 2003 00:11:29 +0000 Subject: Cause CHAR(n) to TEXT or VARCHAR conversion to automatically strip trailing blanks, in hopes of reducing the surprise factor for newbies. Remove redundant operators for VARCHAR (it depends wholly on TEXT operations now). Clean up resolution of ambiguous operators/functions to avoid surprising choices for domains: domains are treated as equivalent to their base types and binary-coercibility is no longer considered a preference item when choosing among multiple operators/functions. IsBinaryCoercible now correctly reflects the notion that you need *only* relabel the type to get from type A to type B: that is, a domain is binary-coercible to its base type, but not vice versa. Various marginal cleanup, including merging the essentially duplicate resolution code in parse_func.c and parse_oper.c. Improve opr_sanity regression test to understand about binary compatibility (using pg_cast), and fix a couple of small errors in the catalogs revealed thereby. Restructure "special operator" handling to fetch operators via index opclasses rather than hardwiring assumptions about names (cleans up the pattern_ops stuff a little). --- doc/src/sgml/release.sgml | 3 +- doc/src/sgml/typeconv.sgml | 75 ++++++++++++++++++++++------------------------ 2 files changed, 37 insertions(+), 41 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml index ea6fe8a7217..32505959644 100644 --- a/doc/src/sgml/release.sgml +++ b/doc/src/sgml/release.sgml @@ -1,5 +1,5 @@ @@ -24,6 +24,7 @@ CDATA means the content is "SGML-free", so you can write without worries about funny characters. --> @@ -45,7 +45,7 @@ mixed-type expressions to be meaningful even with user-defined types. The PostgreSQL scanner/parser decodes lexical elements into only five fundamental categories: integers, floating-point numbers, strings, -names, and key words. Most extended types are first classified as +names, and key words. Constants of most non-numeric types are first classified as strings. The SQL language definition allows specifying type names with strings, and this mechanism can be used in PostgreSQL to start the parser down the correct @@ -134,8 +134,8 @@ The system catalogs store information about which conversions, called perform those conversions. Additional casts can be added by the user with the CREATE CAST command. (This is usually done in conjunction with defining new data types. The set of casts -between the built-in types has been carefully crafted and should not -be altered.) +between the built-in types has been carefully crafted and is best not +altered.) @@ -144,8 +144,8 @@ at proper behavior for SQL standard types. There are several basic type categories defined: boolean, numeric, string, bitstring, datetime, timespan, geometric, network, and user-defined. Each category, with the exception of user-defined, has -a preferred type which is preferentially selected -when there is ambiguity. +one or more preferred types which are preferentially +selected when there is ambiguity. In the user-defined category, each type is its own preferred type. Ambiguous expressions (those with multiple candidate parsing solutions) can therefore often be resolved when there are multiple possible built-in types, but @@ -175,7 +175,8 @@ be converted to a user-defined type (of course, only if conversion is necessary) User-defined types are not related. Currently, PostgreSQL does not have information available to it on relationships between types, other than -hardcoded heuristics for built-in types and implicit relationships based on available functions. +hardcoded heuristics for built-in types and implicit relationships based on +available functions and casts. @@ -203,14 +204,15 @@ should use this new function and will no longer do the implicit conversion using Operators - The operand types of an operator invocation are resolved following + The specific operator to be used in an operator invocation is determined + by following the procedure below. Note that this procedure is indirectly affected by the precedence of the involved operators. See for more information. -Operand Type Resolution +Operator Type Resolution @@ -271,22 +273,16 @@ candidate remains, use it; else continue to the next step. Run through all candidates and keep those with the most exact matches -on input types. Keep all candidates if none have any exact matches. +on input types. (Domain types are considered the same as their base type +for this purpose.) Keep all candidates if none have any exact matches. If only one candidate remains, use it; else continue to the next step. -Run through all candidates and keep those with the most exact or -binary-compatible matches on input types. Keep all candidates if none have -any exact or binary-compatible matches. -If only one candidate remains, use it; else continue to the next step. - - - - -Run through all candidates and keep those that accept preferred types at -the most positions where type conversion will be required. +Run through all candidates and keep those that accept preferred types (of the +input datatype's type category) at the most positions where type conversion +will be required. Keep all candidates if none accept preferred types. If only one candidate remains, use it; else continue to the next step. @@ -295,12 +291,13 @@ If only one candidate remains, use it; else continue to the next step. If any input arguments are unknown, check the type categories accepted at those argument positions by the remaining -candidates. At each position, select the string category if any +candidates. At each position, select the string category +if any candidate accepts that category. (This bias towards string is appropriate since an unknown-type literal does look like a string.) Otherwise, if all the remaining candidates accept the same type category, select that category; otherwise fail because the correct choice cannot be deduced -without more clues. Now discard operator +without more clues. Now discard candidates that do not accept the selected type category. Furthermore, if any candidate accepts a preferred type at a given argument position, discard candidates that accept non-preferred types for that argument. @@ -455,12 +452,12 @@ SELECT CAST('20' AS int8) ! AS "factorial"; Functions - The argument types of function calls are resolved according to the - following steps. + The specific function to be used in a function invocation is determined + according to the following steps. -Function Argument Type Resolution +Function Type Resolution @@ -523,29 +520,24 @@ candidate remains, use it; else continue to the next step. Run through all candidates and keep those with the most exact matches -on input types. Keep all candidates if none have any exact matches. -If only one candidate remains, use it; else continue to the next step. - - - - -Run through all candidates and keep those with the most exact or -binary-compatible matches on input types. Keep all candidates if none have -any exact or binary-compatible matches. +on input types. (Domain types are considered the same as their base type +for this purpose.) Keep all candidates if none have any exact matches. If only one candidate remains, use it; else continue to the next step. -Run through all candidates and keep those that accept preferred types at -the most positions where type conversion will be required. +Run through all candidates and keep those that accept preferred types (of the +input datatype's type category) at the most positions where type conversion +will be required. Keep all candidates if none accept preferred types. If only one candidate remains, use it; else continue to the next step. -If any input arguments are unknown, check the type categories accepted +If any input arguments are unknown, check the type categories +accepted at those argument positions by the remaining candidates. At each position, select the string category if any candidate accepts that category. (This bias towards string @@ -553,8 +545,8 @@ is appropriate since an unknown-type literal does look like a string.) Otherwise, if all the remaining candidates accept the same type category, select that category; otherwise fail because the correct choice cannot be deduced without more clues. -Now discard candidates that do not accept the selected type category; -furthermore, if any candidate accepts a preferred type at a given argument +Now discard candidates that do not accept the selected type category. +Furthermore, if any candidate accepts a preferred type at a given argument position, discard candidates that accept non-preferred types for that argument. @@ -571,6 +563,8 @@ then fail. +Note that the best match rules are identical for operator and +function type resolution. Some examples follow. @@ -649,7 +643,8 @@ SELECT substr(CAST (varchar '1234' AS text), 3); -The parser is aware that text and varchar +The parser learns from the pg_cast catalog that +text and varchar are binary-compatible, meaning that one can be passed to a function that accepts the other without doing any physical conversion. Therefore, no explicit type conversion call is really inserted in this case. -- cgit v1.2.3