Fix / implement GH-15287: add a lazy fetch to Pdo\PgSql

[outtersg]

Make Pdo\PgSql accept Pdo::setAttribute(PDO::ATTR_PREFETCH, 0) to enter libpq's single row mode.
This avoids storing the whole result set in memory before being able to call the first fetch().

[outtersg]

This branch is currently uncomplete as I am struggling to make it work on

$stmt = $pdo->query(…);

as opposed to

$stmt = $pdo->prepare(…);
$stmt->execute();

which works.

This seems to be related by the fact that prepare() preserves the stmt,
while query() releases it just after having executed it (and thus the second fetch() fails).

This is understandable in the traditional fetch mode (a prepared statement might be reused later, while a singly-executed one is of no interest anymore once the result has been received),
but in lazy fetch mode this is problematic (the first result fetch triggers the freeing of the statement before we can fetch more results),
and I don't understand which code triggers that.

Anyone pointing me to the (maybe obvious :-\) difference between execute (in pdo_stmt.c) and query (in pdo_dbh.c), or anywhere else in PDO, would be of a great and appreciated help.

[devnexen]

Nice attempt ! I had a quick glance, I ll have a better look in few days. Fetch with query not working indeed but also I get a crash because of an empty error message.

[outtersg]

@devnexen wrote:

[…] but also I get a crash because of an empty error message.

_pdo_pgsql_trim_message() seems a bit fragile (not able to handle empty strings, due to the unsigned size_t - 1).
Correcting it would be easy, but would mask the real problem (of something passing an empty error message).

But I don't reproduce it here: did you get it with the provided .phpt, or is it triggered by another test case I would be glad to work on?

[devnexen]

@devnexen wrote:

[…] but also I get a crash because of an empty error message.

_pdo_pgsql_trim_message() seems a bit fragile (not able to handle empty strings, due to the unsigned size_t - 1). Correcting it would be easy, but would mask the real problem (of something passing an empty error message).

It is definitively just the symptom.

But I don't reproduce it here: did you get it with the provided .phpt, or is it triggered by another test case I would be glad to work on?

Your new test but I build with asan.

[outtersg]

Multiple reasons required a reorganize of the process, as diagnosed thanks to the failing test's code structure:

$stmt = $pdo->query(…); $stmt->fetchAll();
$stmt = $pdo->query(…); $stmt->fetchAll();

Internally, after having called the second ->query() (which did a PQprepare + the first PQgetResult),
the "=" of the returned value overwrites $stmt: the old value gets GC-decremented and thus freed,
calling the destructor, which contains the DEALLOCATE to tell that the DB statement is of no use anymore.

But:

• PQgetResult() works on the connection, not on the statement: the results cleaning I put in the dtor thus ate the results of the new query :-\
• libpq (or the server?) doesn't like pdo_stmt_00000001 being DEALLOCATEd between pdo_stmt_00000002 preparation and first getResult(), and the subsequent getResult()s. Does it make libpq consider the deceased pdo_stmt_00000001 to be the current statement (and try to getResult() on it?). I don't know but this is what makes the next getResult return a 7 PGRES_FATAL_ERROR
• additionnaly, that PGRES_FATAL_ERROR comes with no PQerrorMessage (hence the subsequent error on trim_message). At least for diagnosis purposes it would be a good idea to handle that specific error by setting a generic message instead of simply the code 7.

[devnexen]

Looking good overall, I ve tested your branch for a while. That will be for after 8.4 tough. few nitpicks so far.

[outtersg]

@devnexen wrote:

That will be for after 8.4 tough.

That's fine. In fact somewhere on StackOverflow I already wrote that "hopefully on PHP 8.5 this will be possible".

[devnexen]

Looking nice ! I ll give another round of tests in few days.

[devnexen]

looking good implementation-wise.

[devnexen]

Thanks !