From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Precision loss casting float to numeric |
Date: | 2018-03-09 17:05:32 |
Message-ID: | CAE2gYzxxwBcGKi3LL1rx-YAadcid1ot92nZPHYsw-9dSMsJGyA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I wonder if an alternative to making a cast that can't be immutable,
>> because it looks at a GUC, could be to offer a choice of cast
>> functions: if you need the other behavior, create a schema, do a
>> CREATE CAST in it, and put it on your search path ahead of pg_catalog.
>
> Nope, because casts aren't schema-local, since they don't have names.
> There can be only one cast between given source and target types.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-03-09 17:37:23 | Re: Implementing SQL ASSERTION |
Previous Message | Pavel Stehule | 2018-03-09 16:48:00 | Re: csv format for psql |