Re: Precision loss casting float to numeric

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.

In response to

Responses

Browse pgsql-hackers by date

  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