Re: - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re:
Date
Msg-id Pine.LNX.4.44.0209132304280.1307-100000@localhost.localdomain
Whole thread Raw
In response to Re:  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Casting rules (was: an untitled thread)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re:  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane writes:

> Shall we abandon all that work and go back to "any available cast can be
> applied implicitly"?
>
> My vote is "tough, time to fix your SQL code".

That would be a OK if the current behavior conformed to the SQL standard,
which it doesn't.  The standard says that all numerical types are mutually
assignable, which in my mind translates directly as implicitly castable.
Additionally, your stance breaks the following SQL compatible and probably
quite common code:

create table test ( a int extract(year from current_date) );

We aren't abandoning "all that work".  Plenty of casts should not be
implicit because they are structurally guaranteed to lose information. But
for casts between numerical types it depends on the content at run time.
Therefore the SQL standard says that the check needs to be at run time.
We do that already, so I don't see a reason to be more strict here.

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: TOAST docs
Next
From: Peter Eisentraut
Date:
Subject: Inconsistent casts