Fix getColumnMeta() for GH-15287 Pdo\Pgsql::setAttribute(PDO::ATTR_PREFETCH, 0)

[outtersg]

As stated in the UPGRADING, using the passthrough ("single-row") mode of libpq forbids passing a new query while the current one's results have not been entirely consumed.
… But I didn't notice that ext/pdo_pgsql internally used new queries to fetch metadata.

This PR makes those internal calls return NULL for non-essential metadata, instead of letting libpq abort the user-called query.

It moreover includes a small tweak to table oid-to-name translation, with a 1-slot cache.
This may by chance allow the internal call to return something instead of NULL,
but it will nonetheless avoid 30 server calls to get the table name of 30 columns of the same table.

[outtersg]

I noticed this week-end that pgsql_driver.c too was full of PQexec (for internal needs).
So those calls too need to be protected the same way (by ensuring that no running statement has been let in a running state).

So 44afde3 exposes pgsql_stmt_finish(), and makes pgsql_driver.c use it extensively (only when the last run statement is in single-row / unbuffered / lazy fetch mode).

… But then I noticed some patterns that could be factorized in pgsql_stmt_finish() (while((pgsql_result = PQgetResult(H->server))) PQclear(pgsql_result);).
I'm a bit stressed that factorized code could break things that presently work, so for now I just put a comment showing the mutualization opportunity (and the result is quite stable, I'm currently testing it with production cases),
but should I fully explore finishing the code mutualization?

[devnexen]

… But then I noticed some patterns that could be factorized in pgsql_stmt_finish() (while((pgsql_result = PQgetResult(H->server))) PQclear(pgsql_result);). I'm a bit stressed that factorized code could break things that presently work, so for now I just put a comment showing the mutualization opportunity (and the result is quite stable, I'm currently testing it with production cases), but should I fully explore finishing the code mutualization?

Sure, you can always explore in your own fork for a while and see how it goes. 8.5 release is in 1 year + :)

[outtersg]

@devnexen wrote:

Sure, you can always explore in your own fork for a while and see how it goes. 8.5 release is in 1 year + :)

That's a good point!

Now as I both rebased and amended, the changes are not that clear in the last diff :-\
Here starts the change to pdo_pgsql.

[outtersg]

Now that 8.4 is out, it's time to think of 8.5.

Although the nature of the PR (fixing an incompatibility between prefetch mode and metadata reading) could have made it a candidate for a 8.4.x,
the changes make it sufficently risky that I prefer keeping the 8.5 target (and if necessary document the 8.4 with a warning that "for now, entering the prefetch mode prevents using getColumnMeta() or anythng else meta calling the database's information schema").

This is a first, working pass on the subject, while I found time to code it: it is a technically self-sustainable fix, although we could go further in what pgsql_finish_running_stmt() is a first try at: separating functional PQexecs (the ones from exec(), passing the user queries) from technical ones (called internally by getColumnMeta() and such).
Then:

• any internal query, depending on a mandatory parameter, would either throw ("Cannot access the meta schema in the middle of a result consumption") or silently return nothing (e.g. in getColumnMeta(), if we cannot resolve a user-defined type to its pretty name, we can still return its OID).
• later, when implementing libpq's pipeline mode, we could implement in this centralized function the complexity of taking advantage of the pipeline mode, to direct those synchronous meta-select queries to a dedicated "channel" where they could execute even while the user-pulled result is in the middle of its fetch.

But as I am not sure of the time I could devote to this ideal solution,
let's keep this PR focused on its first goal of just preventing unexplainable libpq error codes.