Re: Casting INT4 to BOOL... - Mailing list pgsql-patches

From Tom Lane
Subject Re: Casting INT4 to BOOL...
Date
Msg-id 27591.1097552931@sss.pgh.pa.us
Whole thread Raw
In response to Re: Casting INT4 to BOOL...  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Casting INT4 to BOOL...  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List pgsql-patches
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Mon, 11 Oct 2004, Sean Chittenden wrote:
>> 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.

So?  The type input function also accepts 't', 'f', and other spellings
that are not in the input domain for an integer-to-bool coercion.  Will
you argue we should remove those allowed inputs so that it can be 100%
compatible with the coercion?

The question for an integer-to-bool conversion is what is useful and
expected behavior for that conversion; I don't think that's necessarily
the same as what the textual conversion should do.

A possibly useful analogy is that real-to-integer coercion rounds off
fractions; it doesn't error out, even though the integer input function
won't take a string that includes a decimal point.

To pollute this abstract discussion with an actual fact ;-) ...
I note from recent discussion on the ODBC list that M$ Access likes
to use "-1" to represent TRUE.  So it would certainly make life easier
for Access migrants if the int-to-bool coercion would accept -1.

            regards, tom lane

pgsql-patches by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Casting INT4 to BOOL...
Next
From: Neil Conway
Date:
Subject: Re: Casting INT4 to BOOL...