Thread: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
From
Ranier Vilela
Date:
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> ok done
msvc 2019 (64 bits), is worried about it:
"C:\dll\postgres\pgsql.sln" (default target) (1) ->
"C:\dll\postgres\cyrillic_and_mic.vcxproj" (default target) (37) ->
"C:\dll\postgres\postgres.vcxproj" (default target) (38) ->
(ClCompile target) ->
C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334: '<<': resultado de 32-bit shift convertido implicitamente para 64 bits (64-bit shift era pretendid
o?) [C:\dll\postgres\postgres.vcxproj]
1 Warning(s)
0 Error(s)
"C:\dll\postgres\cyrillic_and_mic.vcxproj" (default target) (37) ->
"C:\dll\postgres\postgres.vcxproj" (default target) (38) ->
(ClCompile target) ->
C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334: '<<': resultado de 32-bit shift convertido implicitamente para 64 bits (64-bit shift era pretendid
o?) [C:\dll\postgres\postgres.vcxproj]
1 Warning(s)
0 Error(s)
"result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)"
regards,
Ranier Vilela
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
From
Tom Lane
Date:
Ranier Vilela <ranier.vf@gmail.com> writes: > msvc 2019 (64 bits), is worried about it: > C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334: > '<<': resultado de 32-bit shift convertido implicitamente para 64 bits > (64-bit shift era pretendid > o?) [C:\dll\postgres\postgres.vcxproj] Yeah, most/all of the MSVC buildfarm members are showing this warning too. The previous coding was Int64GetDatum((int64) (1 << count)) which apparently is enough to silence MSVC, though it makes no difference as to the actual overflow risk involved. I'm a bit inclined to make the new code be NumericGetDatum(int64_to_numeric(INT64CONST(1) << count)); ie do the shift in 64 bits. That's either free or next door to free, and it allows larger count values to be accepted. The existing callers don't care of course, but someday somebody might try to expose this function more widely. regards, tom lane
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
From
Ranier Vilela
Date:
Em seg., 14 de set. de 2020 às 15:33, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
> msvc 2019 (64 bits), is worried about it:
> C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334:
> '<<': resultado de 32-bit shift convertido implicitamente para 64 bits
> (64-bit shift era pretendid
> o?) [C:\dll\postgres\postgres.vcxproj]
Yeah, most/all of the MSVC buildfarm members are showing this warning too.
The previous coding was
Int64GetDatum((int64) (1 << count))
which apparently is enough to silence MSVC, though it makes no difference
as to the actual overflow risk involved.
I'm a bit inclined to make the new code be
NumericGetDatum(int64_to_numeric(INT64CONST(1) << count));
+1
msvc 2019 (64 bits), is happy with INT64CONST(1)
regards,
Ranier Vilela