Re: [HACKERS] ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8'

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
>> I concur --- I'd be inclined to leave FLOAT8 as the top of the
>> hierarchy. But NUMERIC could be stuck in there between int and float,
>> no? (int-vs-numeric ops certainly must be promoted to numeric...)

> Is this topic related to the fact that 1.1 is an FLOAT8 constant in
> PostgreSQL ?

No, not directly. At least I don't think the question of how constants
are handled forces our decision about which direction the default
promotion should go.

> I've not understood at all why it's OK.

There's a really, really crude hack in scan.l that prevents a long
numeric constant from being converted to FLOAT8. Otherwise we'd lose
precision from making the value float8 and later converting it to
numeric (after type analysis had discovered the necessity for it to
be numeric). I think this is pretty ugly, not to say inconsistent,
since the parser's behavior can change depending on how many digits
you type:

regression=# select * from num_data where val = 12345678901234.56;
ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8'
You will have to retype this query using an explicit cast
regression=# select * from num_data where val = 12345678901234.567;
id | val
----+-----
(0 rows)

The second case works because it's treated exactly like
select * from num_data where val = '12345678901234.567';
and here, the resolution of an UNKNOWN-type string constant saves
the day.

I proposed a while back that T_Float tokens ought to carry the value in
string form, rather than actually converting it to float, so that we
behave consistently while taking no precision risks until the target
type is known for certain. Thomas seems not to want to do it that way,
for some reason.

regards, tom lane