From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Document parameter count limit |
Date: | 2022-11-23 18:30:48 |
Message-ID: | Y35m2JHf5apnhFd1@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 10, 2022 at 11:01:18AM -0700, David G. Johnston wrote:
> On Thu, Nov 10, 2022 at 10:58 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>
>
> + <entry>if you are reading this prepatorily, please redesign your
> query to use temporary tables or arrays</entry>
>
>
> I agree with the documentation of this parameter.
> I agree with dissuading anyone from attempting to change it
> The wording is bordering on snark (however well deserved) and I think the
> voice is slightly off.
>
> Alternate suggestion:
>
>
> Queries approaching this limit usually can be refactored to use arrays
> or temporary tables, thus reducing parameter overhead.
>
>
> The bit about parameter overhead appeals to the reader's desire for
> performance, rather than just focusing on "you shouldn't want this".
>
>
> Yeah, the wording is a bit tongue-in-cheek. Figured assuming a committer wants
> this at all we'd come up with better wording. I like your suggestion.
Does this come up enough to document it? I assume the error message the
user receives is clear.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
From | Date | Subject | |
---|---|---|---|
Next Message | Roberto C. Sánchez | 2022-11-23 18:35:27 | Re: Question concerning backport of CVE-2022-2625 |
Previous Message | Ankit Kumar Pandey | 2022-11-23 18:18:20 | Questions regarding distinct operation implementation |