Re: Boolean casting in 7.3 -> changed?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Ian Barwick <barwick(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Boolean casting in 7.3 -> changed?
Date: 2002-11-27 23:18:42
Message-ID: 28836.1038439122@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Ian Barwick writes:
>> "Casting integers to boolean (for example, 0::bool) is no longer allowed,
>> use '0'::bool instead".

> This advice would probably only cause more confusion, because we are now
> moving into the direction that character strings are no longer acceptable
> as numeric data.

Yes, phrased that way it's just misleading. We do not and did not have
a general int-to-bool cast (though it may be reasonable to add one, now
that we could mark it explicit-only). The case that worked in 7.2 and
before was only for numeric-looking *literals* being cast to bool (or
any other type for that matter) --- parser_typecast_constant would
essentially act as though the literal had quotes around it, whether
it actually did or not. Thus in the old code, the validity of, say,
42::bool
would depend on whether bool's input converter would accept the string
'42'. In the new code, 42 is taken to be an int4 constant and the
validity of the expression depends on whether there is an int4-to-bool
cast.

7.2:

regression=# select 42::bool;
ERROR: Bad boolean external representation '42'

Current:

regression=# select 42::bool;
ERROR: Cannot cast type integer to boolean

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-11-27 23:56:31 Planning for improved versions of IN/NOT IN
Previous Message scott.marlowe 2002-11-27 23:08:49 Re: [spam] Re: [mail] Re: Native Win32 sources