Skip site navigation (1) Skip section navigation (2)

Re: Casting INT4 to BOOL...

From: Sean Chittenden <chitt(at)speakeasy(dot)net>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Casting INT4 to BOOL...
Date: 2004-10-12 01:54:09
Message-ID: 9B4D76AA-1BF1-11D9-BCB2-000A95C705DC@speakeasy.net (view raw or flat)
Thread:
Lists: pgsql-patches
>> Is there any reason why the backend doesn't cast an unquoted integer 
>> to
>> a boolean value?
>
> Can you add some regression tests, please?

:-/  I have zero understanding or knowledge of the regression test 
suite.  Given the simplicity of the casts, does this really need a 
require a regression test?  I could've written it as: 
"return(PG_GETARG_INT32(0) ? true : false);" and saved a few lines of 
code... there's no chance or room for a bug or change in behavior 
unless C changes its trinary operator.... and that's not gunna happen 
until hell freezes over and we've all taken up skiing.

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

> The patch changes the system catalog; it probably ought to also bump 
> the
> catalog version number. That also means this probably isn't 8.0
> material, unless we make an unrelated system catalog change in a future
> beta (... and even then, I'm not sure if I'd cal it a bug fix).

System catalog bumps have been coming through with some degree of 
regularity so I wasn't worried about providing the patch to bump the 
catalog date.  -sc

-- 
Sean Chittenden


In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2004-10-12 02:07:36
Subject: Re: Casting INT4 to BOOL...
Previous:From: Neil ConwayDate: 2004-10-12 01:44:29
Subject: more code cleanup

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group