From: Tom Lane Date: Wed, 30 Jul 2008 21:23:17 +0000 (+0000) Subject: Allow I/O conversion casts to be applied to or from any type that is a member X-Git-Tag: REL8_4_BETA1~1123 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=c8572986ad138142acbf3215bb14214926e25ce5;p=postgresql Allow I/O conversion casts to be applied to or from any type that is a member of the STRING type category, thereby opening up the mechanism for user-defined types. This is mainly for the benefit of citext, though; there aren't likely to be a lot of types that are all general-purpose character strings. Per discussion with David Wheeler. --- diff --git a/contrib/citext/expected/citext.out b/contrib/citext/expected/citext.out index 7c207f4e9c..9a60b93490 100644 --- a/contrib/citext/expected/citext.out +++ b/contrib/citext/expected/citext.out @@ -1141,13 +1141,16 @@ SELECT like_escape( name::text, ''::citext ) =like_escape( name::text, '' ) AS t t (5 rows) ---- TODO: Get citext working with magic cast functions? -SELECT cidr( '192.168.1.2'::citext ) = cidr( '192.168.1.2'::text ) AS "t TODO"; -ERROR: function cidr(citext) does not exist -LINE 1: SELECT cidr( '192.168.1.2'::citext ) = cidr( '192.168.1.2'::... - ^ -HINT: No function matches the given name and argument types. You might need to add explicit type casts. -SELECT '192.168.1.2'::cidr::citext = '192.168.1.2'::cidr::text AS "t TODO"; -ERROR: cannot cast type cidr to citext -LINE 1: SELECT '192.168.1.2'::cidr::citext = '192.168.1.2'::cidr::te... - ^ +--- citext should work as source or destination of I/O conversion casts +SELECT cidr( '192.168.1.2'::citext ) = cidr( '192.168.1.2'::text ) AS "t"; + t +--- + t +(1 row) + +SELECT '192.168.1.2'::cidr::citext = '192.168.1.2'::cidr::text AS "t"; + t +--- + t +(1 row) + diff --git a/contrib/citext/sql/citext.sql b/contrib/citext/sql/citext.sql index 04a297da02..8df3e93219 100644 --- a/contrib/citext/sql/citext.sql +++ b/contrib/citext/sql/citext.sql @@ -323,6 +323,6 @@ SELECT COUNT(*) = 19::bigint AS t FROM try; SELECT like_escape( name, '' ) = like_escape( name::text, '' ) AS t FROM srt; SELECT like_escape( name::text, ''::citext ) =like_escape( name::text, '' ) AS t FROM srt; ---- TODO: Get citext working with magic cast functions? -SELECT cidr( '192.168.1.2'::citext ) = cidr( '192.168.1.2'::text ) AS "t TODO"; -SELECT '192.168.1.2'::cidr::citext = '192.168.1.2'::cidr::text AS "t TODO"; +--- citext should work as source or destination of I/O conversion casts +SELECT cidr( '192.168.1.2'::citext ) = cidr( '192.168.1.2'::text ) AS "t"; +SELECT '192.168.1.2'::cidr::citext = '192.168.1.2'::cidr::text AS "t"; diff --git a/doc/src/sgml/ref/create_cast.sgml b/doc/src/sgml/ref/create_cast.sgml index ea56f66857..080f31832d 100644 --- a/doc/src/sgml/ref/create_cast.sgml +++ b/doc/src/sgml/ref/create_cast.sgml @@ -1,4 +1,4 @@ - + @@ -26,7 +26,7 @@ CREATE CAST (sourcetype AS targettype - + Description @@ -131,6 +131,18 @@ SELECT CAST ( 2 AS numeric ) + 4.0; to int4, are best made explicit-only. + + + Sometimes it is necessary for usability or standards-compliance reasons + to provide multiple implicit casts among a set of types, resulting in + ambiguity that cannot be avoided as above. The parser has a fallback + heuristic based on type categories and preferred + types that can help to provide desired behavior in such cases. See + for + more information. + + + To be able to create a cast, you must own the source or the target data type. To create a binary-coercible cast, you must be superuser. @@ -181,8 +193,8 @@ SELECT CAST ( 2 AS numeric ) + 4.0; - Indicates that the source type and the target type are binary - coercible, so no function is required to perform the cast. + Indicates that the source type is binary-coercible to the target type, + so no function is required to perform the cast. @@ -218,7 +230,7 @@ SELECT CAST ( 2 AS numeric ) + 4.0; if there is none. The third argument, if present, must be type boolean; it receives true if the cast is an explicit cast, false otherwise. - (Bizarrely, the SQL spec demands different behaviors for explicit and + (Bizarrely, the SQL standard demands different behaviors for explicit and implicit casts in some cases. This argument is supplied for functions that must implement such casts. It is not recommended that you design your own data types so that this matters.) @@ -271,7 +283,8 @@ SELECT CAST ( 2 AS numeric ) + 4.0; It is normally not necessary to create casts between user-defined types and the standard string types (text, varchar, and - char(n)). PostgreSQL will + char(n), as well as user-defined types that + are defined to be in the string category). PostgreSQL will automatically handle a cast to a string type by invoking the other type's output function, or conversely handle a cast from a string type by invoking the other type's input function. These @@ -340,16 +353,15 @@ SELECT CAST ( 2 AS numeric ) + 4.0; Examples - To create a cast from type bigint to type + To create an assignment cast from type bigint to type int4 using the function int4(bigint): -CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint); +CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint) AS ASSIGNMENT; (This cast is already predefined in the system.) - Compatibility @@ -358,7 +370,7 @@ CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint); SQL standard, except that SQL does not make provisions for binary-coercible types or extra arguments to implementation functions. - AS IMPLICIT is a PostgreSQL + AS IMPLICIT is a PostgreSQL extension, too. diff --git a/src/backend/parser/parse_coerce.c b/src/backend/parser/parse_coerce.c index df5ad09bae..df1fb8526d 100644 --- a/src/backend/parser/parse_coerce.c +++ b/src/backend/parser/parse_coerce.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_coerce.c,v 2.162 2008/07/30 17:05:04 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_coerce.c,v 2.163 2008/07/30 21:23:17 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1796,8 +1796,8 @@ find_coercion_pathway(Oid targetTypeId, Oid sourceTypeId, /* * If we still haven't found a possibility, consider automatic casting - * using I/O functions. We allow assignment casts to textual types - * and explicit casts from textual types to be handled this way. (The + * using I/O functions. We allow assignment casts to string types + * and explicit casts from string types to be handled this way. (The * CoerceViaIO mechanism is a lot more general than that, but this is * all we want to allow in the absence of a pg_cast entry.) It would * probably be better to insist on explicit casts in both directions, @@ -1807,14 +1807,10 @@ find_coercion_pathway(Oid targetTypeId, Oid sourceTypeId, if (result == COERCION_PATH_NONE) { if (ccontext >= COERCION_ASSIGNMENT && - (targetTypeId == TEXTOID || - targetTypeId == VARCHAROID || - targetTypeId == BPCHAROID)) + TypeCategory(targetTypeId) == TYPCATEGORY_STRING) result = COERCION_PATH_COERCEVIAIO; else if (ccontext >= COERCION_EXPLICIT && - (sourceTypeId == TEXTOID || - sourceTypeId == VARCHAROID || - sourceTypeId == BPCHAROID)) + TypeCategory(sourceTypeId) == TYPCATEGORY_STRING) result = COERCION_PATH_COERCEVIAIO; } }