Re: Casting INT4 to BOOL...

>>> 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...



--
Sean Chittenden