pgsql: Expose internal function for converting int64 to numeric
Expose internal function for converting int64 to numeric
Existing callers had to take complicated detours via
DirectFunctionCall1(). This simplifies a lot of code.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: /messages/by-id/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/0aa8f764088ea0f36620ae2955fa6c54ec736c46
Modified Files
--------------
contrib/btree_gist/btree_numeric.c | 2 +-
contrib/jsonb_plperl/jsonb_plperl.c | 4 +-
src/backend/utils/adt/cash.c | 7 +-
src/backend/utils/adt/dbsize.c | 21 ++----
src/backend/utils/adt/formatting.c | 19 ++----
src/backend/utils/adt/jsonpath_exec.c | 11 +---
src/backend/utils/adt/numeric.c | 116 +++++++++-------------------------
src/include/utils/numeric.h | 2 +
8 files changed, 50 insertions(+), 132 deletions(-)
On Thu, 10 Sep 2020 at 06:41, Peter Eisentraut <peter@eisentraut.org> wrote:
src/backend/utils/adt/dbsize.c | 21 ++----
This change introduced a new compiler warning on MSVC.
src\backend\utils\adt\dbsize.c(630): warning C4334: '<<': result of
32-bit shift implicitly converted to 64 bits (was 64-bit shift
intended?)
I see all of the calls all bit shift by a constant that''s always
below 32. So there's no actual danger here, but the attached at least
silences the warning.
I'll push it in a bit if nobody has other ideas.
David