| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Erik Wienhold <ewie(at)ewie(dot)name>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Underscore in positional parameters? |
| Date: | 2024-05-17 00:06:55 |
| Message-ID: | Zkafn08nGVU2ucaC@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 16, 2024 at 08:41:11AM +0200, Peter Eisentraut wrote:
> On this specific patch, maybe reword "parameter too large" to "parameter
> number too large".
WFM here.
> Also, I was bemused by the use of atol(), which is notoriously unportable
> (sizeof(long)). So I poked around and found more places that might need
> fixing. I'm attaching a patch here with annotations too look at later.
Yeah atoXX calls have been funky in the tree for some time. This
reminds this thread, somewhat:
https://www.postgresql.org/message-id/CALAY4q8be6Qw_2J%3DzOp_v1X-zfMBzvVMkAfmMYv%3DUkr%3D2hPcFQ%40mail.gmail.com
The issue is also that there is no "safe" parsing alternative for 64b
integers in the frontend (as you know long is 32b in Windows, which is
why I'd encourage ripping it out as much as we can). This may be
better as a complementary of strtoint() in src/common/string.c. Note
as well strtoint64() in pgbench.c. I think I have a patch lying
around, actually..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2024-05-17 00:09:55 | Re: optimizing pg_upgrade's once-in-each-database steps |
| Previous Message | Michael Paquier | 2024-05-16 23:55:07 | Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled |