Re: [HACKERS] Roadmap for FE/BE protocol redesign

Tom Lane wrote:
> * Backend should pass its version number, database encoding, default
> client encoding, and possibly other data (any ideas?) to frontend during
> startup, to avoid need for explicit queries to get this info.  We could
> also consider eliminating SET commands sent by libpq in favor of adding
> variable settings to startup packet's PGOPTIONS field.  Ideally we could
> get back to the point where a standard connection startup takes only one
> packet in each direction.

Should we pass this in a way where we can add stuff later, like passing
it as a simple NULL-terminated string that can get split up on the
client end.

> One of the $64 questions that has to be answered is how much work we're
> willing to expend on backwards compatibility.  The path of least
> resistance would be to handle it the same way we've done protocol
> revisions in the past: the backend will be able to handle both old and new
> protocols (so it can talk to old clients) but libpq would be revised to
> speak only the new protocol (so new/recompiled clients couldn't talk to
> old backends).  We've gotten away with this approach in the past, but the
> last time was release 6.4.  I fully expect to hear more complaints now.

I think such compatibility is sufficient.  We can mention in the
releases notes that they should upgrade there servers before their
clients.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073