Tom Lane wrote:
>> > Raul Chirea <[EMAIL PROTECTED]> writes:
>> > > So, it seems to be a parser difficulty (bug) to correctly determine
>> > > the type of a numeric constant with decimals (like 99.9).
>> >
>> > We've been aware of the problem for a while but are unsure as yet
>> > how to solve it without breaking other cases --- ie, cases where
>> > you *do* want such a constant to be treated as float not numeric.
>> >
>> > For the moment, we have left the behavior as it's always been in
>> > Postgres (ie, undecorated non-integral constants are taken to be
>> > 'float8'), so as not to break existing applications.
>>
>
> Bruce Momjian wrote:
>
>> test=> create table tab1(x numeric);
>> CREATE
>> test=> insert into tab1 values (1);
>> INSERT 20937 1
>> test=> update tab1 set x=4 where x=5;
>> UPDATE 0
>> test=> update tab1 set x=4.0 where x=5;
>> UPDATE 0
>> test=> update tab1 set x=4 where x=5.0;
>> ERROR: Unable to identify an operator '=' for types 'numeric'
>> and
>> 'float8'
>> You will have to retype this query using an explicit cast
>>
>> test=>
>>
>> This is terrible. I can't imagine how people use this without terrible
>> problems. Why don't we get more bug reports about this?
>>
>
I don't know nothing about postgres internals but I imagine that it is
possible to treat float and numeric constants in an omogenuous
manner because basicaly numeric and float type are the same, only
the storage mode in a field differs. Or it may be possible to do an
automatic cast between float and numeric type.
I may just have told some stupid things, but it's only an opinion.
:-)
This problem bothers me because if one (me, for example ;-) tries to
use a client program that compose the select automaticaly (i.e. Delphi
table component) and there is no way to manually cast that expression
(i.e. "where <numeric_field> = 12345.67::numeric") this is a real problem !
Bye.
