Re: float4in_internal - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: float4in_internal
Date
Msg-id b862e588-3d47-e591-a436-938594559488@dunslane.net
Whole thread Raw
In response to Re: float4in_internal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2022-12-21 We 10:33, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: postgres_fdw planning issue: EquivalenceClass changes confuse it
Next
From: Thomas Munro
Date:
Subject: Re: psql tab-complete