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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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
Дата:
Сообщение: Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING