| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Use of "long" in incremental sort code |
| Date: | 2020-07-02 18:07:03 |
| Message-ID: | CAH2-WznYKm_KO8NVCoAtPYxx-t9e4ir6R8=uMFxsFn+Hz8fzdA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 2, 2020 at 10:53 AM James Coleman <jtc331(at)gmail(dot)com> wrote:
> Do you think it's reasonable to use int64 across the board for memory
> and disk space numbers then? If so, I can update the patch.
Using int64 as a replacement for long is the safest general strategy,
and so ISTM that it might be worth doing that even in cases where it
isn't clearly necessary. After all, any code that uses long must have
been written with the assumption that that was the same thing as
int64, at least on most platforms.
There is nothing wrong with using Size/size_t, and doing so is often
slightly clearer. But it's no drop-in replacement for long.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mitar | 2020-07-02 18:55:38 | Persist MVCC forever - retain history |
| Previous Message | Joe Conway | 2020-07-02 18:05:54 | Re: pg_read_file() with virtual files returns empty string |