On Thu, Mar 23, 2023 at 01:54:05PM +0000, Imseih (AWS), Sami wrote: > Yes, that is possible but we will need to add a libpq API > that allows the caller to pass in a "fetch size". > PQsendQueryParams does not take in a "fetch size", > so it returns all rows, through PQsendQueryParams > > https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-exec.c#L1882 > > Adding such an API that takes in a "fetch size" will be beneficial > not just for this test, but I can see it enabling another psql meta command, > similar to \bind but that takes in a "fetch size".
So... The idea here is to set a custom fetch size so as the number of calls can be deterministic in the tests, still more than 1 for the tests we'd have. And your point is that libpq enforces always 0 when sending the EXECUTE message causing it to always return all the rows for any caller of PQsendQueryGuts(). The extended protocol allows that, so you would like a libpq API to have more control of what we send with EXECUTE: https://www.postgresql.org/docs/current/protocol-overview.html#PROTOCOL-QUERY-CONCEPTS The extended query protocol would require multiple 'E' messages, but we would not need multiple describe or bind messages, meaning that this cannot just be an extra flavor PQsendQueryParams(). Am I gettig that right? The correct API design seems tricky, to say the least. Perhaps requiring this much extra work in libpq for the purpose of having some tests in this thread is not a brilliant idea.. Or perhaps we could just do it and have something a-la-JDBC with two routines? That would be one libpq routine for describe/bind and one for execute where the limit can be given by the caller in the latter case, similar to sendDescribeStatement() and sendExecute() in QueryExecutorImpl.java. -- Michael
signature.asc
Description: PGP signature
