Re: float4in_internal
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-21T22:01:30Z
Lists: 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
Commits
-
Introduce float4in_internal
- 33dd895ef331 16.0 landed
-
Improve portability of I/O behavior for the geometric types.
- 50861cd683e8 9.6.0 cited