Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility
От | Marko Kreen |
---|---|
Тема | Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility |
Дата | |
Msg-id | CACMqXCLopGHczKYhr8epc3ofkYDkq2=U+QV3Dz21oNmxHoEwxQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Mon, Jan 23, 2012 at 5:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer <fweimer@bfk.de> wrote: >> * Robert Haas: >>>> In this particular case, I knew that the change was coming and could >>>> push updated Java and Perl client libraries well before the server-side >>>> change hit our internal repository, but I really don't want to have to >>>> pay attention to such details. >>> >>> But if we *don't* turn this on by default, then chances are very good >>> that it will get much less use. That doesn't seem good either. If >>> it's important enough to do it at all, then IMHO it's important enough >>> for it to be turned on by default. We have never made any guarantee >>> that the binary format won't change from release to release. >> >> The problem here are libpq-style drivers which expose the binary format >> to the application. The Java driver doesn't do that, but the Perl >> driver does. (However, both transparently decode BYTEA values received >> in text format, which led to the compatibility issue.) > > I can see where that could cause some headaches... but it seems to me > that if we take that concern seriously, it brings us right back to > square one. If breaking the binary format causes too much pain to > actually go do it, then we shouldn't change it until we're breaking > everything else anyway (i.e. new protocol version, as Tom suggested). My suggestion - please avoid per-session-protocol. Either something is Postgres version-dependent or it can be toggled/tracked per request. That means any data can either be passed through, or you need to understand formats of Postgres version X.Y. This kind of hints at per-request "gimme-formats-from-version-x.y" flag for ExecuteV4 packet. Or some equivalent of it. Anything that cannot be processed without tracking per-session state over whole stack (poolers/client frameworks) is major pain to maintain. -- marko
В списке pgsql-hackers по дате отправления: