Subject: Re: Roadmap for FE/BE protocol redesign
From: Rod Taylor <rbt@rbt.ca>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>,
	pgsql-interfaces@postgresql.org
In-Reply-To: <19041.1047322279@sss.pgh.pa.us>
References: <19041.1047322279@sss.pgh.pa.us>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-VM78m/2Mbud7aV7UGHvX"
Organization: 
Message-Id: <1047324016.99075.31.camel@jester>
Mime-Version: 1.0
Date: 10 Mar 2003 14:20:17 -0500

--=-VM78m/2Mbud7aV7UGHvX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> * Backend's ReadyForQuery message (Z message) should carry an indication
> of current transaction status (idle/in transaction/in aborted transaction)
> so that frontend need not guess at state.  Perhaps also indicate
> autocommit status.  (Is there anything else that frontends would Really
> Like To Know?)

Could it include transaction depth with the assumption nested
transactions will arrive at some point?

> * XML support?  If we do anything, I'd want some extensible solution to
> allowing multiple query-result output formats from the backend, not an
> XML-specific hack.  For one thing, that would allow the actual appearance
> of any XML support to happen later.

> 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 wouldn't worry about backward compatibility complaints too much BUT
I'd be tempted to make a startup packet that will allow libpq to revert
back to old protocols easily enough for the future so that we can do=20
incremental changes to the protocol.

--=20
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

--=-VM78m/2Mbud7aV7UGHvX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQA+bOVw6DETLow6vwwRAj7SAJwP8dALe5T2KFOUsvEEBTKifyo/UgCfQSB3
6ub05hkXdYrjbxShp07Hk28=
=/q+B
-----END PGP SIGNATURE-----

--=-VM78m/2Mbud7aV7UGHvX--