To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign 
In-reply-to: <200303101915.h2AJF3x20844@candle.pha.pa.us> 
References: <200303101915.h2AJF3x20844@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
	message dated "Mon, 10 Mar 2003 14:15:02 -0500"
Date: Mon, 10 Mar 2003 14:24:54 -0500
Message-ID: <19245.1047324294@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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