Re: Document parameter count limit

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Document parameter count limit
Date: 2023-10-26 23:13:07
Message-ID: CAKFQuwZ5MjVFnH7TT+UsJUvft3N2goT0SEMzDNKnuS1y2gh38Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 26, 2023 at 4:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Ah, I was confused. I documented both in the attached patch.
>
> The function one should have the same annotation as some others:
>
> <entry>can be increased by recompiling
> <productname>PostgreSQL</productname></entry>
>
>
I'd like to see a comment on the parameter count one too.

"Alternatives include using a temporary table or passing them in as a
single array parameter."

About the only time this is likely to come up is with many parameters of
the same type and meaning, pointing that out with the array option seems
excessively wordy for the comment area.

Needs a comma: 65,535

Kinda think both should be tacked on to the end of the table. I'd also put
function arguments first so it appears under the compile time partition
keys limit.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2023-10-26 23:17:19 Re: Document parameter count limit
Previous Message Tom Lane 2023-10-26 23:08:01 Re: Document parameter count limit