Thread: float4in_internal

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.

We could probably call these two internal functions directly in
numeric_float4() and numeric_float8() - not sure if it's worth it rght
now but we might end up wanting something like that for error-safe casts.


cheers


andrew


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

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.)

            regards, tom lane

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