Current status: implicit-coercion issues for 7.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Current status: implicit-coercion issues for 7.3
Date: 2002-09-01 01:18:08
Message-ID: 14289.1030843088@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-09-01 01:21:52 Re: pgindent
Previous Message Bruce Momjian 2002-09-01 00:52:34 pgindent