Re: [PATCHES] Casting INT4 to BOOL...

[Bruce Momjian]

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 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 inconsistent.
> 
> test=> SELECT 1::BOOL, 0::BOOL, TRUE::INT4, FALSE::INT4;
>   bool | bool | int4 | int4
> --+--+--+--
>   t| f|1 |0
> (1 row)
> 
> Okey doke, both directions are now provided and the cast has to be 
> explicit.  -sc
> 

[ Attachment, skipping... ]

> 
> 
> -- 
> Sean Chittenden

> 
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to [EMAIL PROTECTED] so that your
>   message can get through to the mailing list cleanly

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PATCHES] Casting INT4 to BOOL...

[Bruce Momjian]

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 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 inconsistent.
> 
> test=> SELECT 1::BOOL, 0::BOOL, TRUE::INT4, FALSE::INT4;
>   bool | bool | int4 | int4
> --+--+--+--
>   t| f|1 |0
> (1 row)
> 
> Okey doke, both directions are now provided and the cast has to be 
> explicit.  -sc
> 

[ Attachment, skipping... ]

> 
> 
> -- 
> Sean Chittenden

> 
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to [EMAIL PROTECTED] so that your
>   message can get through to the mailing list cleanly

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PATCHES] Casting INT4 to BOOL...

[Andrew Dunstan]

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

(ITMY precedent)

FYI, perl does not quite do this. Both "" and "0" are false. Any other
string is true.

Of course, the Unix shell treats an exit value of 0 as success and non-zero
as failure, so the rule is hardly universal.

Personally, I would prefer to make boolean as opaque as possible. But I
don't care that much.

>
>
> ... I wonder what color this bikeshed is gunna be...

purple.

cheers

andrew



---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [PATCHES] Casting INT4 to BOOL...

[Sean Chittenden]

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.
However, AFAIK it's inconsitent with the type input function which
supports '1' and '0' but not other integers.
I actually pondered that and came up with a patch that I didn't submit. 
 False has a very specific set of possibilities that can be reasonably 
easily defined.  True, is anything not false.  I eventually didn't 
submit it because I was able to convince myself with the following 
statement.

Regardless of whether or not true is any non-zero value, this is a 
database where data and its inputs must be validated and constrained to 
a given set of probable and process-able possibilities.  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 false.

Unlike the previous int4_bool()/bool_int4() patch which addresses a 
mathematical technicality, accepting different string values as true or 
false seems exceedingly dangerous, though probably an okay 
interpretation.  I went one step further, however, and tested for an 
empty string as a valid false value (one of Perl's false values).

Since this subject isn't ever going to get resolved, I don't think it's 
worth trudging down this path, but, I thought the extreme is helpful in 
justifying the current string->bool conversion and the new 
int4->bool/bool->int4 conversion, IMHO.  -sc

... I wonder what color this bikeshed is gunna be...
Index: bool.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/bool.c,v
retrieving revision 1.35
diff -u -r1.35 bool.c
--- bool.c  29 Aug 2004 05:06:49 -  1.35
+++ bool.c  12 Oct 2004 07:52:14 -
@@ -37,29 +37,12 @@
 
switch (*b)
{
-   case 't':
-   case 'T':
-   if (pg_strncasecmp(b, "true", strlen(b)) == 0)
-   PG_RETURN_BOOL(true);
-   break;
-
case 'f':
case 'F':
if (pg_strncasecmp(b, "false", strlen(b)) == 0)
PG_RETURN_BOOL(false);
break;
 
-   case 'y':
-   case 'Y':
-   if (pg_strncasecmp(b, "yes", strlen(b)) == 0)
-   PG_RETURN_BOOL(true);
-   break;
-
-   case '1':
-   if (pg_strncasecmp(b, "1", strlen(b)) == 0)
-   PG_RETURN_BOOL(true);
-   break;
-
case 'n':
case 'N':
if (pg_strncasecmp(b, "no", strlen(b)) == 0)
@@ -70,17 +53,11 @@
if (pg_strncasecmp(b, "0", strlen(b)) == 0)
PG_RETURN_BOOL(false);
break;
-
-   default:
-   break;
+   case '\0':
+   PG_RETURN_BOOL(false);
}
 
-   ereport(ERROR,
-   (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
-errmsg("invalid input syntax for type boolean: \"%s\"", b)));
-
-   /* not reached */
-   PG_RETURN_BOOL(false);
+   PG_RETURN_BOOL(true);
 }
 
 /*

--
Sean Chittenden

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PATCHES] Casting INT4 to BOOL...

[Peter Eisentraut]

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 => 
'2'::text is not arbitrary in my mind, but 1::int => true is just something a 
C programmer could make up.)  But I'm clearly in the minority here.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [PATCHES] Casting INT4 to BOOL...

[Stephan Szabo]

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 input function which
> > supports '1' and '0' but not other integers.
>

[strawman snipped]

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

Well, technically AFAICS, a string to integer conversion has to follow the
same general rules as numeric to integer by SQL99.  So a varchar value of
'2.5' cast to int should work and give you the same value as 2.5 cast to
int (or at least, I can't see any other way to read 6.22GR6b). But since
we do odd things with quoted literals, it makes the case anyway and I
withdraw the comment.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [PATCHES] Casting INT4 to BOOL...

[Neil Conway]

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 output from src/test/regress/results to
src/test/regress/expected

> Given the simplicity of the casts, does this really need a 
> require a regression test?

Yeah, I suppose not. Personally I'd always err on the side of doing more
testing rather than less (I don't see much point in striving for
minimalism in a test suite), but you're right that this functionality is
probably sufficiently trivial it doesn't need tests.

-Neil



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [PATCHES] Casting INT4 to BOOL...

[Tom Lane]

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

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [PATCHES] Casting INT4 to BOOL...

[Stephan Szabo]

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


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] Casting INT4 to BOOL...

[Sean Chittenden]

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 the beta cycle.  I've got mixed emotions about
that myself.  The odds of breaking anything with this patch seem
essentially zero, and we have certainly seen this requested multiple
times before, so one part of me says "sure, push it in".  But from a
project-management standpoint it's hard to justify not saying "it's got
to wait for 8.1".
*puts on patch advocate's hat*
From a feature/usability standpoint, it'd be "more convenient" to have 
booleans behave consistently starting with the 8.X branch as opposed to 
saying, "starting with 8.1, booleans can be explicitly cast to integers 
and visa versa."  From a patch maintainer stand point, given the work 
of the original patch, it's hardly worth the effort to maintain and 
given the possibility of OIDs being used, waiting is more work than 
committing it now.  :)

The patch changes the system catalog; it probably ought to also bump
the catalog version number.

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
I think the agreed protocol is that the descriptive text should
remind the committer to bump the catversion upon application.  Just
to make sure he doesn't forget ;-)
Fair enough... though with this discussion it would seem like a rather 
unnecessary cudgel to the head.  Next time I'll bump it when adding a 
built-in function, however.  Thanks for the protocol FYI.  -sc

--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] Casting INT4 to BOOL...

[Tom Lane]

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 feature addition, small though
it be, at this stage of the beta cycle.  I've got mixed emotions about
that myself.  The odds of breaking anything with this patch seem
essentially zero, and we have certainly seen this requested multiple
times before, so one part of me says "sure, push it in".  But from a
project-management standpoint it's hard to justify not saying "it's got
to wait for 8.1".

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

I can't see anything wrong with it either.  Throwing an error for
anything except 0 or 1 would be the other possibility, but that doesn't
seem like it really buys anything.

>> The patch changes the system catalog; it probably ought to also bump 
>> the catalog version number.

> 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

I think the agreed protocol is that the descriptive text should
remind the committer to bump the catversion upon application.  Just
to make sure he doesn't forget ;-)

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PATCHES] Casting INT4 to BOOL...

[Sean Chittenden]

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
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [PATCHES] Casting INT4 to BOOL...

[Tom Lane]

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'd cal it a bug fix).

We've already forced an initdb for beta4, so I think any additional
reasons for forcing one are "free" until beta4 goes out.  But having
said that, this is clearly a feature not a bug.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [PATCHES] Casting INT4 to BOOL...

[Neil Conway]

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 an integer representation of
"true"? (I'm not sure myself, I just don't think copying C here is
necessarily the best guide.)

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

-Neil



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] Casting INT4 to BOOL...

[Sean Chittenden]

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 inconsistent.
test=> SELECT 1::BOOL, 0::BOOL, TRUE::INT4, FALSE::INT4;
 bool | bool | int4 | int4
--+--+--+--
 t| f|1 |0
(1 row)
Okey doke, both directions are now provided and the cast has to be 
explicit.  -sc

Index: src/backend/utils/adt/int.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/int.c,v
retrieving revision 1.63
diff -u -r1.63 int.c
--- src/backend/utils/adt/int.c 4 Oct 2004 14:42:46 -   1.63
+++ src/backend/utils/adt/int.c 11 Oct 2004 18:28:41 -
@@ -361,6 +361,15 @@
return result;
 }
 
+Datum
+int4_bool(PG_FUNCTION_ARGS)
+{
+   if (PG_GETARG_INT32(0) == 0)
+   PG_RETURN_BOOL(false);
+   else
+   PG_RETURN_BOOL(true);
+}
+
 
 /*
  * 
Index: src/backend/utils/adt/bool.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/bool.c,v
retrieving revision 1.35
diff -u -r1.35 bool.c
--- src/backend/utils/adt/bool.c29 Aug 2004 05:06:49 -  1.35
+++ src/backend/utils/adt/bool.c11 Oct 2004 18:28:41 -
@@ -127,6 +127,18 @@
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
 }
 
+/*
+ * bool_int4 - Casts a boolean to an INT4
+ */
+Datum
+bool_int4(PG_FUNCTION_ARGS)
+{
+   if (PG_GETARG_INT32(0) == 0)
+   PG_RETURN_BOOL(false);
+   else
+   PG_RETURN_BOOL(true);
+}
+
 
 /*
  *  PUBLIC ROUTINES   
  *
Index: src/include/utils/builtins.h
===
RCS file: /projects/cvsroot/pgsql/src/include/utils/builtins.h,v
retrieving revision 1.251
diff -u -r1.251 builtins.h
--- src/include/utils/builtins.h4 Oct 2004 22:49:59 -   1.251
+++ src/include/utils/builtins.h11 Oct 2004 18:28:41 -
@@ -76,6 +76,7 @@
 extern Datum isnotfalse(PG_FUNCTION_ARGS);
 extern Datum booland_statefunc(PG_FUNCTION_ARGS);
 extern Datum boolor_statefunc(PG_FUNCTION_ARGS);
+extern Datum bool_int4(PG_FUNCTION_ARGS);
 
 /* char.c */
 extern Datum charin(PG_FUNCTION_ARGS);
@@ -111,6 +112,7 @@
 extern Datum i4toi2(PG_FUNCTION_ARGS);
 extern Datum int2_text(PG_FUNCTION_ARGS);
 extern Datum text_int2(PG_FUNCTION_ARGS);
+extern Datum int4_bool(PG_FUNCTION_ARGS);
 extern Datum int4_text(PG_FUNCTION_ARGS);
 extern Datum text_int4(PG_FUNCTION_ARGS);
 extern Datum int4eq(PG_FUNCTION_ARGS);
Index: src/include/catalog/pg_cast.h
===
RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_cast.h,v
retrieving revision 1.16
diff -u -r1.16 pg_cast.h
--- src/include/catalog/pg_cast.h   4 Oct 2004 22:49:54 -   1.16
+++ src/include/catalog/pg_cast.h   11 Oct 2004 18:28:41 -
@@ -80,6 +80,7 @@
 DATA(insert (  21  700  236 i ));
 DATA(insert (  21  701  235 i ));
 DATA(insert (  21 1700 1782 i ));
+DATA(insert (  23  16  2557 e ));
 DATA(insert (  23   20  481 i ));
 DATA(insert (  23   21  314 a ));
 DATA(insert (  23  700  318 i ));
@@ -381,4 +382,9 @@
 DATA(insert ( 1562 1562 1687 i ));
 DATA(insert ( 1700 1700 1703 i ));
 
+/*
+ * Misc. coercion functions (ex: bool)
+ */
+DATA(insert (  16  23  2558 e ));
+
 #endif   /* PG_CAST_H */
Index: src/include/catalog/pg_proc.h
===
RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.348
diff -u -r1.348 pg_proc.h
--- src/include/catalog/pg_proc.h   7 Oct 2004 18:38:50 -   1.348
+++ src/include/catalog/pg_proc.h   11 Oct 2004 18:28:42 -
@@ -3604,6 +3604,11 @@
 DATA(insert OID = 2556 ( pg_tablespace_databases   PGNSP PGUID 12 f f t t s 1 26 
"26" _null_ pg_tablespace_databases - _null_));
 DESCR("returns database oids in a tablespace");
 
+DATA(insert OID = 2557 ( bool PGNSP PGUID 12 f f t f i 1  
16 "23" _null_   int4_bool - _null_ ));
+DESCR("convert int4 to boolean");
+DATA(insert OID = 2558 ( int4 PGNSP PGUID 12 f f t f i 1  
23 "16" _null_   bool_int4 - _null_ ));
+DESCR("convert boolean to int4");
+
 
 /*
  * Symbolic values for provolatile column: these indicate whether the result

--
Sean Chittenden

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  su

Re: [PATCHES] Casting INT4 to BOOL...

[Tom Lane]

"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/automatic casts
any more than Peter does, but I don't see a strong argument against
providing explicit casts.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] Casting INT4 to BOOL...

[Michael Paesold]

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 
not using it, would it?

Best Regards,
Michael Paesold 

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PATCHES] Casting INT4 to BOOL...

[Peter Eisentraut]

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 front in that the value 1 should be considered
> true and 0 should be considered false.  My $0.02.  -sc

That's really Qt's problem.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [PATCHES] Casting INT4 to BOOL...

[Sean Chittenden]

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 it before committing?  :)

Also, what about the other direction?  Providing a cast in only one
direction is pretty inconsistent.
Ah... well, if you want that, I can provide that too.  Personally, I 
could care less about the BOOL->INT direction than INT->BOOL.  In C++, 
any bool value is either 0 or 1 and you can do such weirdness 
(brokeness?) as:

bool val = false;
if (val == 0) { /* blah */ }
Anyway, with Qt, it converts bool values to integers.  I think Qt's 
probably right on this front in that the value 1 should be considered 
true and 0 should be considered false.  My $0.02.  -sc

--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster