Re: float4in_internal

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: float4in_internal
Date: 2022-12-21 22:01:30
Message-ID: b862e588-3d47-e591-a436-938594559488@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2022-12-21 We 10:33, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> The attached patch factors out the guts of float4in so that the new
>> float4in_internal function is callable without going through the fmgr
>> call sequence. This will make adjusting the seg module's input function
>> to handle soft errors simpler. A similar operation was done for float8in
>> some years ago in commit 50861cd683e. The new function has an identical
>> argument structure to float8in_internal.
> Looks reasonable except for one nitpick: the "out of range" message
> in the ERANGE case should be kept mentioning real, not the passed
> type_name, to be equivalent to the way float8in_internal does it.
> I lack enough caffeine to recall exactly why float8in_internal
> does it that way, but the comments are exceedingly clear that it was
> intentional, and I'm sure the same rationale would apply here.
>
> (float8in_internal also goes out of its way to show just the part of
> the string that is the number in that case, but I'm willing to let
> that pass for now.)
>
>

Thanks for reviewing.

I made both these changes, to keep the two functions more closely aligned.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-12-21 22:41:08 Re: psql tab-complete
Previous Message Tom Lane 2022-12-21 21:57:18 postgres_fdw planning issue: EquivalenceClass changes confuse it