> 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().
That is correct. > 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? Correct, there will need to be separate APIs for Parse/Bind, Execute and Close of a Portal. > 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. I am not too clear on your point here. ISTM you are suggesting adding new libpq APis similar to JDBC, which is what I am also suggesting. Did I understand correctly? -- Sami Imseih Amazon Web Services (AWS)
