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.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml
index d5b2b627dd..de6bf7697f 100644
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -80,6 +80,12 @@
<entry>can be increased by recompiling <productname>PostgreSQL</productname></entry>
</row>
+ <row>
+ <entry>function arguments</entry>
+ <entry>65535</entry>
+ <entry></entry>
+ </row>
+
<row>
<entry>indexes per table</entry>
<entry>unlimited</entry>
