Current status: implicit-coercion issues for 7.3 - Mailing list pgsql-hackers

From Tom Lane
Subject Current status: implicit-coercion issues for 7.3
Date
Msg-id 14289.1030843088@sss.pgh.pa.us
Whole thread Raw
Responses Re: Current status: implicit-coercion issues for 7.3  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Although it seems no one who's thought about it is very happy with the
current state of play for implicit casts, we have run out of time to
implement any real solution for 7.3.

After looking through the archives, it seems that the only serious
step backwards from 7.2 behavior is Barry Lind's example:

> create table test (cola bigint);
> update test set cola = 10000000000;
> ERROR:  column "cola" is of type 'bigint' but expression is of type 
> 'double precision'

which fails because the constant is initially typed as float8.  To patch
this up, I have marked the float8->int8 cast pathway as an implicitly
invokable cast.  This is not desirable, but it's no worse than what 7.2
would do.

I would still like to see us reduce the number of implicit cast
pathways, but that will have to wait for 7.4 now, since there's no
more time for discussion about the behavior.


It does seem that in at least a few places, current sources behave better
than 7.2 did; for instance the example mentioned in TODO works:
o SELECT col FROM tab WHERE numeric_col = 10.1 fails, requires quotes

regression=# explain select * FROM tab WHERE numeric_col = 10.1;                    QUERY PLAN
-----------------------------------------------------Seq Scan on tab  (cost=0.00..22.50 rows=5 width=32)  Filter:
(numeric_col= 10.1::numeric)
 
(2 rows)

However the behavior with bigint columns is no better than before.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: pgindent
Next
From: Tom Lane
Date:
Subject: Re: pgindent