Commit bb7e5dc2 authored by Tom Lane's avatar Tom Lane

Tweak TypeCategory to treat new BIT types as of STRING category, rather

than not knowing what they are at all.  Perhaps they should have their own
type category?  Hard to say.  In the meantime, doing it this way allows
SELECT 'unknown' || 'unknown' to continue being resolved as textcat,
instead of spitting out an ambiguous-operator error.
parent b64e7685
...@@ -8,7 +8,7 @@ ...@@ -8,7 +8,7 @@
* *
* *
* IDENTIFICATION * IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/parser/parse_coerce.c,v 2.40 2000/03/23 07:36:03 tgl Exp $ * $Header: /cvsroot/pgsql/src/backend/parser/parse_coerce.c,v 2.41 2000/04/08 19:29:40 tgl Exp $
* *
*------------------------------------------------------------------------- *-------------------------------------------------------------------------
*/ */
...@@ -331,6 +331,19 @@ TypeCategory(Oid inType) ...@@ -331,6 +331,19 @@ TypeCategory(Oid inType)
result = STRING_TYPE; result = STRING_TYPE;
break; break;
/*
* Kluge added 4/8/00 by tgl: treat the new BIT types as strings,
* so that 'unknown' || 'unknown' continues to resolve as textcat
* rather than generating an ambiguous-operator error. Probably
* BIT types should have their own type category, or maybe they
* should be numeric? Need a better way of handling unknown types
* first.
*/
case (ZPBITOID):
case (VARBITOID):
result = STRING_TYPE;
break;
case (OIDOID): case (OIDOID):
case (REGPROCOID): case (REGPROCOID):
case (INT2OID): case (INT2OID):
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment