Re: Casting INT4 to BOOL...
От
Sean Chittenden
Тема
Re: Casting INT4 to BOOL...
Дата
Msg-id
9B4D76AA-1BF1-11D9-BCB2-000A95C705DC@speakeasy.net
Ответ на
Re: Casting INT4 to BOOL... (Neil Conway)
Список
Дерево обсуждения
Casting INT4 to BOOL... Sean Chittenden <chitt@speakeasy.net>
Re: Casting INT4 to BOOL... Tom Lane <tgl@sss.pgh.pa.us>
Re: Casting INT4 to BOOL... Sean Chittenden <chitt@speakeasy.net>
Re: Casting INT4 to BOOL... Peter Eisentraut <peter_e@gmx.net>
Re: Casting INT4 to BOOL... Sean Chittenden <chitt@speakeasy.net>
Re: Casting INT4 to BOOL... Bruce Momjian <pgman@candle.pha.pa.us>
Re: Casting INT4 to BOOL... Bruce Momjian <pgman@candle.pha.pa.us>
Re: Casting INT4 to BOOL... Neil Conway <neilc@samurai.com>
Re: Casting INT4 to BOOL... Tom Lane <tgl@sss.pgh.pa.us>
Re: Casting INT4 to BOOL... Sean Chittenden <chitt@speakeasy.net>
Re: Casting INT4 to BOOL... Neil Conway <neilc@samurai.com>
Re: Casting INT4 to BOOL... Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Casting INT4 to BOOL... Tom Lane <tgl@sss.pgh.pa.us>
Re: Casting INT4 to BOOL... Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Casting INT4 to BOOL... Sean Chittenden <chitt@speakeasy.net>
Re: Casting INT4 to BOOL... "Andrew Dunstan" <andrew@dunslane.net>
Re: Casting INT4 to BOOL... Tom Lane <tgl@sss.pgh.pa.us>
Re: Casting INT4 to BOOL... Sean Chittenden <chitt@speakeasy.net>
Re: Casting INT4 to BOOL... Peter Eisentraut <peter_e@gmx.net>
>> 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
В списке pgsql-patches по дате отправления