Re: float4in_internal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: float4in_internal
Date: 2022-12-21 15:33:35
Message-ID: 1352557.1671636815@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-12-21 16:36:34 Re: Array initialisation notation in syscache.c
Previous Message Tom Lane 2022-12-21 15:18:47 Re: generic plans and "initial" pruning