| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> | 
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: "long" type is not appropriate for counting tuples | 
| Date: | 2019-04-29 21:29:44 | 
| Message-ID: | CAKJS1f81hLP6x1W09PEGWmqVDEPhgw+ybgLwifBTp2LSHnm+Ow@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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.
--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-04-29 22:07:07 | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 | 
| Previous Message | Tom Lane | 2019-04-29 21:12:29 | Re: speeding up planning with partitions |