Re: Underscore in positional parameters?

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Erik Wienhold <ewie(at)ewie(dot)name>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-07-02 21:51:37
Message-ID: fd259565-7a29-4df7-afdb-40ec209a4a7b@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02.07.24 16:14, Tom Lane wrote:
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
>> I had to revert the test case from the 0002 patch. It ended up running
>> some build farm machines out of memory.
>
> That ties into what I said upthread: why are we involving MaxAllocSize
> in this at all? The maximum parameter number you can actually use in
> extended queries is 65535 (because 16-bit fields), and I can't see a
> good reason to permit more.

There are arguably a few things that could be done in this area of code
to improve it, like consistently using int16 and strtoint16 and so on
for parameter numbers. But that's a different project.

The change here was merely to an existing check that apparently wanted
to avoid some kind of excessive memory allocation but did so
ineffectively by checking against INT_MAX, which had nothing to do with
how the memory allocation checking actually works. The fixed code now
avoids the error for "invalid memory alloc request size", but of course
it can still fail if the OS does not have enough memory.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-07-02 22:05:09 Re: Built-in CTYPE provider
Previous Message Tom Lane 2024-07-02 21:49:09 Re: On disable_cost