Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Date
Msg-id CAEudQAr8DuPthQL=exCBdGipb7aUYFx6=dOzsX=FPqTEsSRWDA@mail.gmail.com
Whole thread Raw
In response to Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
Next
From: Alvaro Herrera
Date:
Subject: Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING