Patch applied by Neil. Thanks.
---
Sean Chittenden wrote:
> >> Is there any reason why the backend doesn't cast an unquoted integer
> >> to
> >> a boolean value?
> >
> > Hidden cross-category typecasts are evil. I'd acce
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Sean Chittenden wrote:
> >> Is there any reason why the backend doesn't cast an unquoted integer
> >> to
> >> a boolean
Sean Chittenden said:
> 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 f
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 consisten
Am Montag, 11. Oktober 2004 15:50 schrieb Tom Lane:
> I agree with Michael's position. I don't like implicit/automatic casts
> any more than Peter does, but I don't see a strong argument against
> providing explicit casts.
I find the chosen mapping to be somewhat arbitrary and artifical. (2::int
On Mon, 11 Oct 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> 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 inp
On Tue, 2004-10-12 at 11:54, Sean Chittenden wrote:
> :-/ I have zero understanding or knowledge of the regression test
> suite.
It is trivial: add some SQL to src/test/regress/sql/foo.sql, run the
tests, hand-verify the output (e.g. by looking at regression.diffs), and
then copy the updated out
Stephan Szabo <[EMAIL PROTECTED]> 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 o
On Mon, 11 Oct 2004, Sean Chittenden wrote:
> > 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
Can you add some regression tests, please?
Given the simplicity of the casts, does this really need a
require a regression test?
That request seems quite over-the-top to me too. The real problem here
is just whether we want to be accepting a feature addition, small
though
it be, at this stage of
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> Can you add some regression tests, please?
> Given the simplicity of the casts, does this really need a
> require a regression test?
That request seems quite over-the-top to me too. The real problem here
is just whether we want to be accepting a fe
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
Neil Conway <[EMAIL PROTECTED]> writes:
> 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
On Sun, 2004-10-10 at 16:27, Sean Chittenden wrote:
> Is there any reason why the backend doesn't cast an unquoted integer to
> a boolean value?
Can you add some regression tests, please?
The patch treats any non-zero value as "true". Is that the behavior we
want, or should we only allow "1" as
Is there any reason why the backend doesn't cast an unquoted integer
to
a boolean value?
Hidden cross-category typecasts are evil. I'd accept this as an
explicit cast ('e' in pg_cast) but not automatic.
Also, what about the other direction? Providing a cast in only one
direction is pretty incons
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I oppose casts from boolean to integer or vice versa.
> Even _explicit_ casts only? It would not have any bad side effects on people
> not using it, would it?
I agree with Michael's position. I don't like implicit/automa
Peter Eisentraut wrote:
Sean Chittenden wrote:
Alrighty. Do you want an updated patch for the single character
tweak or can you futz with it before committing? :)
I oppose casts from boolean to integer or vice versa.
Even _explicit_ casts only? It would not have any bad side effects on people
no
Sean Chittenden wrote:
> Alrighty. Do you want an updated patch for the single character
> tweak or can you futz with it before committing? :)
I oppose casts from boolean to integer or vice versa.
> Anyway, with Qt, it converts bool values to integers. I think Qt's
> probably right on this fro
Is there any reason why the backend doesn't cast an unquoted integer
to
a boolean value?
Hidden cross-category typecasts are evil. I'd accept this as an
explicit cast ('e' in pg_cast) but not automatic.
Alrighty. Do you want an updated patch for the single character tweak
or can you futz with i
19 matches
Mail list logo
