Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Added to TODO:
> * Add pg_attribute.atttypmod/Resdom->restypmod to PGresult structure
> This is a good suggestion.
This will require a frontend/backend protocol change, no?
If so, right now would be a great time to address it; I'm about halfway
through rewriting libpq for the asynchronous-query support we discussed
last week, and would be happy to make the client-side mods while I still
have the code in my head.
As long as we are opening up the protocol, there is an incredibly grotty
hack in libpq that I'd like to get rid of. It's hard for me to be
sure whether it's even necessary, but: when libpq gets a 'C' response
(which the documentation says is a "completed response") it assumes that
this is *not* the end of the transaction, and that the only way to be
sure that everything's been read is to send an empty query and wait for
the empty query's 'I' response to be returned.
case 'C': /* portal query command, no rows returned */
/*
* since backend may produce more than one result
* for some commands need to poll until clear.
* Send an empty query down, and keep reading out of
* the pipe until an 'I' is received.
*/
Does this ring a bell with anyone? I'm prepared to believe that it's
useless code, but have no easy way to be sure.
Needless to say, if there really is an ambiguity then the *right* answer
is to fix the protocol so that the end of a query/response cycle is
unambiguously determinable. It looks to me like this hack is costing us
an extra round trip to the server for every ordinary query. That sucks.
regards, tom lane
