Re: Precision loss casting float to numeric

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: emre(at)hasegeli(dot)com
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-18 02:04:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
> 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

FWIW, the behavior of these casts is intended to model what the SQL
standard says about the behavior of "exact numeric" vs "approximate
numeric" types. (In our implementation, the integral types plus numeric
are in the first category, float4 and float8 in the second.) The spec is
perfectly clear that you can assign an approximate numeric to an exact
numeric, or vice versa, without any explicit cast. It is also clear that
arithmetic operations combining approximate and exact are allowed without
a cast, and yield approximate results. These rules lead to our
conclusions that exact -> approximate is an implicit cast (so that the
parser will choose eg. float8 multiplication over numeric multiplication
if you write numericvar * float8var) while approximate -> exact is an
assignment cast (so that you can assign float8 to numeric without explicit
casting). If the decisions had been driven purely by "what risks silent
precision loss", no doubt we'd have done it differently ... but it's hard
to do that and still meet the letter of the spec.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-18 02:09:41 Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Previous Message Kefan Yang 2018-03-18 02:00:21 Re: [GSoC 2018] Proposal Draft