From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | emre(at)hasegeli(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Precision loss casting float to numeric |
Date: | 2018-03-17 23:17:54 |
Message-ID: | 5AADA222.1050800@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Huong Dangminh | 2018-03-17 23:43:22 | PostgreSQL 10: Segmentation fault when using GROUPING SETS with all unsortable columns |
Previous Message | Chapman Flack | 2018-03-17 23:10:20 | Re: pgbench randomness initialization |