Re: Precision loss casting float to numeric

Поиск
Список
Период
Сортировка
От Emre Hasegeli
Тема Re: Precision loss casting float to numeric
Дата
Msg-id CAE2gYzxxwBcGKi3LL1rx-YAadcid1ot92nZPHYsw-9dSMsJGyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Precision loss casting float to numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: csv format for psql
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Implementing SQL ASSERTION