int4 <-> bool casts

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/

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

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

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/

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

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