Re: int4 <-> bool casts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: int4 <-> bool casts
Date: 2005-02-28 19:37:19
Message-ID: 24579.1109619439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Nicolai Tufar 2005-02-28 19:42:37 Re: snprintf causes regression tests to fail
Previous Message Bruce Momjian 2005-02-28 19:01:16 Re: Patch for Array min() / max()