Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes

Phil Thompson <phil@river-bank.demon.co.uk> writes:
> Tom Lane wrote:
>> We should change the protocol version number to 2.0.
>> It would be possible for the backend to continue to support 1.0 clients,
>> if you think it's worth the trouble to do so.

> Or 1.1?  The changes don't seem too traumatic.

Well, pqcomm.h says that an incompatible change should have a new major
version number, and minor though these changes be, they *are*
incompatible.

> Either way, maintaining support for 1.0 is important as not all of us
> use libpq and we need time to catch up.

No argument from me.  It shouldn't be hard to emit the new stuff
conditionally.

>> Command Done
>> Byte1('Z')

> The completion response already does this for successful queries, and
> the error response for unsuccessful ones.

You missed the point: it is possible to send more than one SQL command
in a single query string.  The reason that libpq sends empty queries is
to determine whether the backend is actually done processing the string.
I suppose we could instead try to make libpq smart enough to parse the
string it's sending and determine how many responses to expect ... but
it seems much easier and more robust to have the backend tell us when
it's done.

> From looking at a dump of the data between psql and the backend for
> 6.3.2 I don't think that those empty queries are issued any more.
> I have implemented a pure Tcl frontend that doesn't issue them and I
> haven't seen any problems.

You didn't exercise the cases where they are sent.  A command that
generates a "C" response without tuple data is needed to make libpq
insert an empty query at the moment.  The code is a horrible kluge,
because it only works for cases like
    set geqo to 'off'; show datestyle; select * from table;
and not for, say,
    select * from table1; select * from table2;

psql masks the problem because it splits up your input into separate
commands and hands them to libpq one at a time.  A dumber UI is needed
to exhibit the trouble.  (We should be able to rip out the
command-splitting code from psql after making this change, BTW.
I think it'll be better to have neither psql nor libpq know much of
anything about SQL syntax.)

> The exception to the above is the single empty query sent immediately
> after the frontend has been successfully authenticated.  This is useful

Right.  I didn't plan to remove that one.

            regards, tom lane