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

>
> Tom Lane wrote:
> >
> > PROTOCOL CHANGES:
> >
> > 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. Either way, maintaining
> support for 1.0 is important as not all of us use libpq and we need time
> to catch up. Also we don't want to put barriers in the way of companies
> like Openlink who seem willing to provide support for PostgreSQL in
> commercial products.

Yes, but there will be a month for people to get their third-part stuff
changed, and the changes are pretty straight-forward. Having support
for both in the backend/frontend is going to make that code more
difficult.

If it was only a small change, we could keep it compatable, but it seems
it would be best to just announce it early on. People can start testing
their new drivers long before the beta period begins.

Also, we are making this change well in advance of the beta, so I hope
they would have enough time to make the transition.

> > The backend will emit this message at completion of processing of every
> > command string, just before it resumes waiting for frontend input.
> > This change eliminates libpq's current hack of issuing empty queries to
> > see whether the backend is done. Note that 'Z' must be emitted after
> > *every* query or function invocation, no matter how it terminated.
>
> The completion response already does this for successful queries, and
> the error response for unsuccessful ones. I came to the conclusion (but
> not with absolute certainty) a while back that the empty query hack was
> needed for an old feature of the backend that is no longer there. 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.
>
> The exception to the above is the single empty query sent immediately
> after the frontend has been successfully authenticated. This is useful
> because it has the side effect of checking that the user has privileges
> against the particular database - it is better to do this as part of the
> session set up rather than the first real query which may be some time
> later.

Good insight on the libpq interface. I think we need the new return
code because of the possibility of multiple results from the backend.
In the old code, without the empty query, doesn't a query with multiple
statements cause the send/return results to get out of sync.

> > 3. The "Start Copy In" response message is changed from 'D' to 'G',
> > and the "Start Copy Out" response message is changed from 'B' to 'H'.
> > These changes eliminate potential confusion with the data row messages,
> > which also have message codes 'D' and 'B'.
>
> The context means there should be no confusion - but if the protocol is
> being changed anyway then it makes sense to do this.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)