Re: Document parameter count limit

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

In response to

Responses

Browse pgsql-hackers by date

  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