From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Document parameter count limit |
Date: | 2022-11-23 20:33:27 |
Message-ID: | 20221123203327.GL11463@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Bruce Momjian <bruce(at)momjian(dot)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.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-11-23 20:34:03 | Re: fixing CREATEROLE |
Previous Message | Tom Lane | 2022-11-23 20:32:59 | Re: fixing CREATEROLE |