Yes, it rings a bell alright,
When you execute a multiple query (denoted by semicolans) like "set geqo to
'off'; show datestyle; select * from table", you get that multiple returns and
MUST read until you get the 'I'. If you don't, your screwed the next time you
try and read anything cause all that stuff is still in the pipe.
Question though, I didnt think my request would have caused a major protocol
change. I though that the '-1' would simply be replaced by the correct size?
Byron
Tom Lane wrote:
> 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
