[nigrosimone]

See #3856. For every row we make a string for each value and only after we parse it: on 500 rows this is about half of the client time, and it is the biggest part of the gap with postgres 4.

This change was made looking at what postgres 4 does (release notes): the client now reads the rows directly from the socket buffer, int2, int4, oid and bool are decoded from the bytes and text is decoded once. Parsers from setTypeParser get the string as before, array mode, binary mode and pg-cursor are not changed. I did not take the compiled row reader, here it gives little for the added complexity.

median latency, current pg = 1.00   this PR   postgres 4.1
sequential, 100 rows                   0.78           0.63
sequential, 500 rows                   0.66           0.51
pipelined x10, 100 rows                0.59           0.59
pipelined x10, 500 rows                0.50           0.44

With 1 row there is no real change. Measured with the same queries of the benchmark on local PostgreSQL 16 over TCP, not with the benchmark itself.

Test: unit tests compare the values with the parsers, and an integration test checks that a real query takes this path.