On Tue, Jun 9, 2026 at 7:38 AM Rafia Sabih <[email protected]> wrote:
> > > On Fri, 5 Jun 2026 at 19:52, Corey Huinker <[email protected]> > wrote: > >> >>>>> - In the test case, choosing a batch_size > PQ_QUERY_PARAM_MAX_LIMIT >>>>> seems a bit artificial, in that it's a value that can't work for any query >>>>> with parameters, and someone might add sanity checks to batch_size in >>>>> option.c, which would in turn invalidate the test case. A test case with a >>>>> 2-column table should be able to get the same effect any batch_size >>>>> greater >>>>> than half of 65535, yes? >>>>> >>>> >>>> >>>> >>> >> Thinking some more on this part, I think it would be worthwhile to check >> on assignments to batch_size, and issue a NOTICE or WARNING that the set >> value exceeds PQ_QUERY_PARAM_MAX_LIMIT, but does not reject the change >> because this value could theoretically (but very unlikely) get smaller in >> the future and we don't want to mess up any pg_restores or pg_upgrades. >> >> > > I am not able to understand this clearly, are you saying there should be a > new check for this NOTICE/WARNING or should the DEBUG1 message (in the > patch upthread) be a NOTICE/WARNING? > -- > Regards, > Rafia Sabih > CYBERTEC PostgreSQL International GmbH > I'm saying that we may want a separate check when the batch_size option is SET (via CREATE/ALTER TABLE/SERVER) to test the value against PQ_QUERY_PARAM_MAX_LIMIT and issue a NOTICE/WARNING that the chosen value will always have to be set at or below $PQ_QUERY_PARAM_MAX_LIMIT - but still let them store the values as-is.
