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.

diff --git a/src/backend/parser/parse_coerce.c b/src/backend/parser/parse_coerce.c
index 70b2d13aa5b51860f4c457fcd5d7d1280c672075..26b6934b3d555c99b75108071da3f92b6a84aa56 100644 (file)
--- a/src/backend/parser/parse_coerce.c
+++ b/src/backend/parser/parse_coerce.c
@@ -8,7 +8,7 @@
  *
  *
  * 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)
            result = STRING_TYPE;
            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 (REGPROCOID):
        case (INT2OID):