Re: [HACKERS] Roadmap for FE/BE protocol redesign - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: [HACKERS] Roadmap for FE/BE protocol redesign
Date
Msg-id 19245.1047324294@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Roadmap for FE/BE protocol redesign  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-interfaces
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.

> 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.

Yeah, I was envisioning something with multiple labeled fields so that
more stuff can be added later without a protocol change (likewise for
StartupPacket and ErrorMessage).  But again, I don't want this thread to
get into any details about specific tasks --- let's try to get a view of
the forest before we start hewing down individual trees...


>> 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.

I'd be really happy if we can make that stick.  There's enough work to
be done here without trying to develop a multiprotocol version of
libpq.

It would be good to hear some words from the JDBC and ODBC developers
about what sort of plans they'd have for updating those interfaces.
        regards, tom lane


pgsql-interfaces by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign
Next
From: Tom Lane
Date:
Subject: Re: Roadmap for FE/BE protocol redesign