Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
От
Ranier Vilela
Тема
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Дата
Msg-id
CAEudQAr8DuPthQL=exCBdGipb7aUYFx6=dOzsX=FPqTEsSRWDA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Ranier Vilela <ranier.vf@gmail.com>
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Tom Lane <tgl@sss.pgh.pa.us>
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Ranier Vilela <ranier.vf@gmail.com>
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
В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата:
От: Alvaro Herrera
Дата: