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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, petr(dot)fedorov(at)phystech(dot)edu
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Date: 2020-09-14 18:33:53
Message-ID: 1128312.1600108433@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ranier Vilela <ranier(dot)vf(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-09-14 18:39:05 Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
Previous Message Ranier Vilela 2020-09-14 18:11:01 Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch