Re: Roadmap for FE/BE protocol redesign
От | Rod Taylor |
---|---|
Тема | Re: Roadmap for FE/BE protocol redesign |
Дата | |
Msg-id | 1047324016.99075.31.camel@jester обсуждение исходный текст |
Ответ на | Roadmap for FE/BE protocol redesign (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Roadmap for FE/BE protocol redesign
|
Список | pgsql-hackers |
> * 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
В списке pgsql-hackers по дате отправления: