Thread: 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: https://www.postgresql.org/message-id/flat/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