> * 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
incremental changes to the protocol.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
