Re: Conversion error of floating point numbers in pl/pgsql

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Conversion error of floating point numbers in pl/pgsql
Date: 2015-11-18 04:00:21
Message-ID: CAHyXU0xB+AgHK+WPNp_H8=W5fpkzX7sp6jRbjhdPb5-soKF+zg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 17, 2015 at 9:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>>> Hello. I found that 9.5 has an undocumented difference from 9.4
>>> in type cast in pl/pgsql and I think it might better be mentioned
>>> as a change of behavior in release notes.
>>
>>> Whether do you think it is worth mentioning or not in release notes?
>>
>> This seems unnecessarily alarmist to me. Anybody who's in the habit
>> of converting between float4 and float8 will already be used to this
>> behavior, because it is what has always happened everywhere else in
>> the system.
>
> Sure, but that doesn't mean nobody's functions will start behaving
> differently. It seems worth mentioning as a backward compatibility
> issue to me, because if something breaks, it may not be immediately
> obvious why it has gotten broken.

Agreed, but the note should be followed by another one warning against
any expectations of floating point behavior below the precision
threshold :-).

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-11-18 05:32:04 Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change
Previous Message Corey Huinker 2015-11-18 03:33:32 Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?