| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Remove pg_strtouint64(), use strtoull() directly |
| Date: | 2021-12-14 20:42:42 |
| Message-ID: | c7c03d06-c5d8-9a80-071e-0f2d2842e4b1@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 13.12.21 15:44, Tom Lane wrote:
> Our current hard-coded uses of long long are all written on the
> assumption that it's*at least* 64 bits, so we'd survive OK on
> such a platform so long as we don't start confusing it with
> *exactly* 64 bits.
OK, makes sense. Here is an alternative patch. It introduces two
light-weight macros strtoi64() and strtou64() (compare e.g., strtoimax()
in POSIX) in c.h and removes pg_strtouint64(). This moves the
portability layer from numutils.c to c.h, so it's closer to the rest of
the int64 portability code. And that way it is available to not just
server code. And it resolves the namespace collision with the
pg_strtointNN() functions in numutils.c.
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Simplify-the-general-purpose-64-bit-integer-parsi.patch | text/plain | 6.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-12-14 21:13:49 | Re: Column Filtering in Logical Replication |
| Previous Message | Chapman Flack | 2021-12-14 20:42:12 | Life cycles of tuple descriptors |