- 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.
