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

From Emre Hasegeli
Subject Re: Precision loss casting float to numeric
Date
Msg-id CAE2gYzxxwBcGKi3LL1rx-YAadcid1ot92nZPHYsw-9dSMsJGyA@mail.gmail.com
Whole thread Raw
In response to Re: Precision loss casting float to numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Precision loss casting float to numeric  (Chapman Flack <chap@anastigmatix.net>)
Re: Precision loss casting float to numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: csv format for psql
Next
From: Robert Haas
Date:
Subject: Re: Implementing SQL ASSERTION