Thread: int4 <-> bool casts
I've applied a modified version of this patch from seanc:
http://candle.pha.pa.us/mhonarc/patches2/msg00029.html
(Sorry, I've lost the original thread.) The patch as I applied it is
attached. Catalog version bumped.
-Neil
Index: src/backend/utils/adt/int.c
===================================================================
RCS file: /Users/neilc/local/cvs/pgsql/src/backend/utils/adt/int.c,v
retrieving revision 1.64
diff -c -r1.64 int.c
*** src/backend/utils/adt/int.c 31 Dec 2004 22:01:22 -0000 1.64
--- src/backend/utils/adt/int.c 27 Feb 2005 08:06:40 -0000
***************
*** 361,366 ****
--- 361,385 ----
return result;
}
+ /* Cast int4 -> bool */
+ Datum
+ int4_bool(PG_FUNCTION_ARGS)
+ {
+ if (PG_GETARG_INT32(0) == 0)
+ PG_RETURN_BOOL(false);
+ else
+ PG_RETURN_BOOL(true);
+ }
+
+ /* Cast bool -> int4 */
+ Datum
+ bool_int4(PG_FUNCTION_ARGS)
+ {
+ if (PG_GETARG_BOOL(0) == false)
+ PG_RETURN_INT32(0);
+ else
+ PG_RETURN_INT32(1);
+ }
/*
* ============================
Index: src/include/catalog/catversion.h
===================================================================
RCS file: /Users/neilc/local/cvs/pgsql/src/include/catalog/catversion.h,v
retrieving revision 1.255
diff -c -r1.255 catversion.h
*** src/include/catalog/catversion.h 26 Feb 2005 18:43:34 -0000 1.255
--- src/include/catalog/catversion.h 27 Feb 2005 08:29:35 -0000
***************
*** 53,58 ****
*/
/* yyyymmddN */
! #define CATALOG_VERSION_NO 200502261
#endif
--- 53,58 ----
*/
/* yyyymmddN */
! #define CATALOG_VERSION_NO 200502271
#endif
Index: src/include/catalog/pg_cast.h
===================================================================
RCS file: /Users/neilc/local/cvs/pgsql/src/include/catalog/pg_cast.h,v
retrieving revision 1.17
diff -c -r1.17 pg_cast.h
*** src/include/catalog/pg_cast.h 1 Jan 2005 05:43:09 -0000 1.17
--- src/include/catalog/pg_cast.h 27 Feb 2005 08:02:47 -0000
***************
*** 101,106 ****
--- 101,110 ----
DATA(insert ( 1700 700 1745 i ));
DATA(insert ( 1700 701 1746 i ));
+ /* Allow explicit coercions between int4 and bool */
+ DATA(insert ( 23 16 2557 e ));
+ DATA(insert ( 16 23 2558 e ));
+
/*
* OID category: allow implicit conversion from any integral type (including
* int8, to support OID literals > 2G) to OID, as well as assignment coercion
Index: src/include/catalog/pg_proc.h
===================================================================
RCS file: /Users/neilc/local/cvs/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.350
diff -c -r1.350 pg_proc.h
*** src/include/catalog/pg_proc.h 26 Feb 2005 18:43:34 -0000 1.350
--- src/include/catalog/pg_proc.h 27 Feb 2005 07:59:05 -0000
***************
*** 3604,3609 ****
--- 3604,3614 ----
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
Index: src/include/utils/builtins.h
===================================================================
RCS file: /Users/neilc/local/cvs/pgsql/src/include/utils/builtins.h,v
retrieving revision 1.252
diff -c -r1.252 builtins.h
*** src/include/utils/builtins.h 31 Dec 2004 22:03:45 -0000 1.252
--- src/include/utils/builtins.h 27 Feb 2005 08:07:13 -0000
***************
*** 111,116 ****
--- 111,118 ----
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 bool_int4(PG_FUNCTION_ARGS);
extern Datum int4_text(PG_FUNCTION_ARGS);
extern Datum text_int4(PG_FUNCTION_ARGS);
extern Datum int4eq(PG_FUNCTION_ARGS);
Peter Eisentraut wrote: > - Casting back and forth does not preserve information. (This may be > true for some other type pairs as well, but in this case it's true in > almost every instance.) Right, there are many other explicit casts that lose information. In fact, I think that's somewhat the point of an explicit cast -- if a cast didn't lose information, it could be done implicitly. By explicitly casting something, the user is acknowledging that they accept the possibility of lost information. > - It's an arbitary definition that is not obviously supported by > mathematical or similar principles. It has a long standing precedent outside of mathematics, such as in C and derived programming languages. -Neil
Neil Conway wrote: > > I believe I would have objected to an int/bool cast. I do so now > > anyway. > > On what grounds? I can think of a couple of reasons: - Casting back and forth does not preserve information. (This may be true for some other type pairs as well, but in this case it's true in almost every instance.) - It's an arbitary definition that is not obviously supported by mathematical or similar principles. - It opens the door for other silly casts like empty string => false, non-empty string => true. - It's unnecessary because you can express the same thing using other expressions that clearly state what they do. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > That email message is about a timestamp data type. Hmm, it seems that when Bruce removes items from the patch queue, the remaining items are renumbered. You can find the original thread here: http://archives.postgresql.org/pgsql-patches/2004-10/msg00140.php > I believe I would have objected to an int/bool cast. I do so now > anyway. On what grounds? -Neil
Neil Conway wrote: > I've applied a modified version of this patch from seanc: > > http://candle.pha.pa.us/mhonarc/patches2/msg00029.html > > (Sorry, I've lost the original thread.) The patch as I applied it is > attached. Catalog version bumped. That email message is about a timestamp data type. I believe I would have objected to an int/bool cast. I do so now anyway. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Neil Conway wrote: > Peter Eisentraut wrote: > > That email message is about a timestamp data type. > > Hmm, it seems that when Bruce removes items from the patch queue, the > remaining items are renumbered. You can find the original thread here: > > http://archives.postgresql.org/pgsql-patches/2004-10/msg00140.php Oh, sorry, yea, that does happen. I would just shoot him the subject line and the URL for the patches queue. -- 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
Neil Conway wrote: > It has a long standing precedent outside of mathematics, such as in C > and derived programming languages. C doesn't have a boolean type. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> I believe I would have objected to an int/bool cast. I do so now
> anyway.
This was already discussed and agreed to. Since it's an explicit-only
cast, I see no harm in it. And it's certainly been requested often
enough.
> - Casting back and forth does not preserve information. (This may be
> true for some other type pairs as well, but in this case it's true in
> almost every instance.)
On those grounds we should disallow most of the numeric-category casts.
> - It's an arbitary definition that is not obviously supported by
> mathematical or similar principles.
Nonetheless, the convention 0=false, 1=true is widely recognized.
> - It opens the door for other silly casts like empty string => false,
> non-empty string => true.
I haven't seen any requests for any such casts. This cast is responding
to market demand, no more.
> - It's unnecessary because you can express the same thing using other
> expressions that clearly state what they do.
Basically what this is for is building in a feature that people
otherwise build for themselves. On the grounds of "it's unnecessary"
we could throw away large chunks of Postgres :-)
regards, tom lane