Re: Conversion error of floating point numbers in pl/pgsql - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Conversion error of floating point numbers in pl/pgsql
Date
Msg-id CAHyXU0xB+AgHK+WPNp_H8=W5fpkzX7sp6jRbjhdPb5-soKF+zg@mail.gmail.com
Whole thread Raw
In response to Re: Conversion error of floating point numbers in pl/pgsql  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Nov 17, 2015 at 9:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Next
From: Haribabu Kommi
Date:
Subject: Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change