On Thu, Oct 26, 2023 at 3:51 PM Bruce Momjian <br...@momjian.us> wrote:
> On Wed, Nov 23, 2022 at 02:33:27PM -0600, Justin Pryzby wrote: > > On Wed, Nov 23, 2022 at 12:35:59PM -0700, David G. Johnston wrote: > > > On Wed, Nov 23, 2022 at 11:47 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > > > > Bruce Momjian <br...@momjian.us> writes: > > > > > Does this come up enough to document it? I assume the error > message the > > > > > user receives is clear. > > > > > > > > Looks like you get > > > > > > > > if (nParams < 0 || nParams > PQ_QUERY_PARAM_MAX_LIMIT) > > > > { > > > > libpq_append_conn_error(conn, "number of parameters must be > between 0 and %d", > > > > PQ_QUERY_PARAM_MAX_LIMIT); > > > > return 0; > > > > } > > > > > > > > which seems clear enough. > > > > > > > > I think the concern here is that somebody who's not aware that a > limit > > > > exists might write an application that thinks it can send lots of > > > > parameters, and then have it fall over in production. Now, I've got > > > > doubts that an entry in the limits.sgml table will do much to prevent > > > > that scenario. But perhaps offering the advice to use an array > parameter > > > > will be worthwhile even after-the-fact. > > > > Yes, that's what happens :) > > > > I hit that error after increasing the number of VALUES(),() a loader > > used in a prepared statement (and that was with our non-wide tables). > > > > +1 to document the limit along with the other limits. > > Here is a patch to add this. > > We aren't talking about "function arguments" though...is there something wrong with the term "parameters per query"? I suggest we take this opportunity to decide how to handle values > 999 in terms of separators. The existing page is inconsistent. I would prefer adding the needed commas. David J.