> * 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 <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
