>> Is there any reason why the backend doesn't cast an unquoted integer
>> 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
> 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
In response to
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2004-10-12 02:07:36|
|Subject: Re: Casting INT4 to BOOL... |
|Previous:||From: Neil Conway||Date: 2004-10-12 01:44:29|
|Subject: more code cleanup|