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