Re: "long" type is not appropriate for counting tuples

On 2019-Apr-30, David Rowley wrote:

> On Tue, 30 Apr 2019 at 06:28, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> >
> > On Mon, Apr 29, 2019 at 11:20 AM Alvaro Herrera
> > <alvherre(at)2ndquadrant(dot)com> wrote:
> > > Agreed. Here's a patch. I see downthread that you also discovered the
> > > same mistake in _h_indexbuild by grepping for "long"; I got to it by
> > > examining callers of pgstat_progress_update_param and
> > > pgstat_progress_update_multi_param. I didn't find any other mistakes of
> > > the same ilk. Some codesites use "double" instead of "int64", but those
> > > are not broken.
> >
> > This seems fine, though FWIW I probably would have gone with int64
> > instead of uint64. There is generally no downside to using int64, and
> > being to support negative integers can be useful in some contexts
> > (though not this context).
>
> CopyFrom() returns uint64. I think it's better to be consistent in the
> types we use to count tuples in commands.

That's not a bad argument ... but I still committed it as int64, mostly
because that's what pgstat_progress_update_param takes. Anyway, these
are just local variables, not return values, so it's easily changeable
if we determine (??) that unsigned is better.

I don't know if anybody plans to do progress report for COPY, but I hope
we don't find ourselves in a problem when some user claims that they are
inserting more than 2^63 but less than 2^64 tuples.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services