|
8 | 8 | * |
9 | 9 | * |
10 | 10 | * IDENTIFICATION |
11 | | - * $Header: /cvsroot/pgsql/src/backend/parser/parse_coerce.c,v 2.50 2000/11/17 19:57:47petere Exp $ |
| 11 | + * $Header: /cvsroot/pgsql/src/backend/parser/parse_coerce.c,v 2.51 2000/12/15 18:02:47tgl Exp $ |
12 | 12 | * |
13 | 13 | *------------------------------------------------------------------------- |
14 | 14 | */ |
@@ -174,7 +174,6 @@ coerce_type(ParseState *pstate, Node *node, Oid inputTypeId, |
174 | 174 | * This uses the same mechanism as the CAST() SQL construct in gram.y. |
175 | 175 | * We should also check the function return type on candidate conversion |
176 | 176 | *routines just to be safe but we do not do that yet... |
177 | | - * We need to have a zero-filled OID array here, otherwise the cache lookup fails. |
178 | 177 | * - thomas 1998-03-31 |
179 | 178 | */ |
180 | 179 | bool |
@@ -448,14 +447,6 @@ TypeCategory(Oid inType) |
448 | 447 | result=STRING_TYPE; |
449 | 448 | break; |
450 | 449 |
|
451 | | -/* |
452 | | - * Kluge added 4/8/00 by tgl: treat the new BIT types as |
453 | | - * strings, so that 'unknown' || 'unknown' continues to |
454 | | - * resolve as textcat rather than generating an |
455 | | - * ambiguous-operator error. Probably BIT types should have |
456 | | - * their own type category, or maybe they should be numeric? |
457 | | - * Need a better way of handling unknown types first. |
458 | | - */ |
459 | 450 | case (ZPBITOID): |
460 | 451 | case (VARBITOID): |
461 | 452 | result=BITSTRING_TYPE; |
|