The patch treats any non-zero value as "true". Is that the behavior we
want, or should we only allow "1" as an integer representation of
"true"? (I'm not sure myself, I just don't think copying C here is
necessarily the best guide.)
I would posit that this is the desired behavior as it's consistent with
every language I can think of.
However, AFAIK it's inconsitent with the type input function which supports '1' and '0' but not other integers.
I actually pondered that and came up with a patch that I didn't submit. False has a very specific set of possibilities that can be reasonably easily defined. True, is anything not false. I eventually didn't submit it because I was able to convince myself with the following statement.
Regardless of whether or not true is any non-zero value, this is a database where data and its inputs must be validated and constrained to a given set of probable and process-able possibilities. Perl's decision to let any non-empty string be true doesn't mean a database should take any nonfalse-like value and assume it should be true. 42::BOOL == TRUE, on the other hand, has a long mathematical president wherein non-zero values are true and zero values are false.
Unlike the previous int4_bool()/bool_int4() patch which addresses a mathematical technicality, accepting different string values as true or false seems exceedingly dangerous, though probably an okay interpretation. I went one step further, however, and tested for an empty string as a valid false value (one of Perl's false values).
Since this subject isn't ever going to get resolved, I don't think it's worth trudging down this path, but, I thought the extreme is helpful in justifying the current string->bool conversion and the new int4->bool/bool->int4 conversion, IMHO. -sc
... I wonder what color this bikeshed is gunna be...
Index: bool.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/bool.c,v
retrieving revision 1.35
diff -u -r1.35 bool.c
--- bool.c 29 Aug 2004 05:06:49 -0000 1.35
+++ bool.c 12 Oct 2004 07:52:14 -0000
@@ -37,29 +37,12 @@
switch (*b)
{
- case 't':
- case 'T':
- if (pg_strncasecmp(b, "true", strlen(b)) == 0)
- PG_RETURN_BOOL(true);
- break;
-
case 'f':
case 'F':
if (pg_strncasecmp(b, "false", strlen(b)) == 0)
PG_RETURN_BOOL(false);
break;
- case 'y':
- case 'Y':
- if (pg_strncasecmp(b, "yes", strlen(b)) == 0)
- PG_RETURN_BOOL(true);
- break;
-
- case '1':
- if (pg_strncasecmp(b, "1", strlen(b)) == 0)
- PG_RETURN_BOOL(true);
- break;
-
case 'n':
case 'N':
if (pg_strncasecmp(b, "no", strlen(b)) == 0)
@@ -70,17 +53,11 @@
if (pg_strncasecmp(b, "0", strlen(b)) == 0)
PG_RETURN_BOOL(false);
break;
-
- default:
- break;
+ case '\0':
+ PG_RETURN_BOOL(false);
}
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
- errmsg("invalid input syntax for type boolean: \"%s\"", b)));
-
- /* not reached */
- PG_RETURN_BOOL(false);
+ PG_RETURN_BOOL(true);
}
/*
-- Sean Chittenden
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
