Re: Precision loss casting float to numeric - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: Precision loss casting float to numeric
Date
Msg-id 5AADA222.1050800@anastigmatix.net
Whole thread Raw
In response to Re: Precision loss casting float to numeric  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: Precision loss casting float to numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 03/09/18 12:05, Emre Hasegeli wrote:
> In this case, I cannot see any other option than adding those as
> separate cast functions.  Should we mark this entry as "returned with
> feedback"?
> 
> We can also consider turning the current float to numeric casts to
> explicit as they are causing data loss.  I am not sure how much it
> would impact backwards-compatibility.  The counter argument is the
> numeric to float casts being IMPLICIT.  They are causing data loss for
> sure, but I believe there are different reasons to keep them as
> IMPLICIT.

Thanks for the feedback. I will mark it RWF myself, as the backward-
compatibility issues are kind of paralyzing, and I don't think I'll
have time in this CF to give it enough further thought anyway.

I wonder whether even changing a formerly-implicit cast to explicit
would be too much of a behavior change for existing code that expects
the current behavior?

-Chap


pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: pgbench randomness initialization
Next
From: Huong Dangminh
Date:
Subject: PostgreSQL 10: Segmentation fault when using GROUPING SETS with allunsortable columns