<div id="OWAFontStyleDivID"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;"><p>Hi,<br
/><br/> Currently the criteria on updating the F/B protocol is undefined. This makes it hard to update the protocol
goingforward. It makes it also hard to write library/driver/application implementations that will be more future proof
tofuture server versions.<br /><br /> Ideally the documentation for 9.4 (backport?) would say what kind of things are
allowedto change within the v3 protocol, and thus implies what kind of changes need a new v4 protocol. Is there some
wishlistpage of items to do differently for v4 already?<br /><br /> I did find the following text in the documentation:
"binaryrepresentations for complex data types might change across server versions". But having more specific rules
wouldhelp, especially since it seems to be there just to scare: so far changes have been strongly discouraged.<br /><br
/>An example to consider: some binary formats have flags (arrays) or version (jsonb) field. We should explicitly say
thatclients must reject any unknown bits/versions that they do not know about. This guarantees they detect small format
updatesinstead of silently accepting then and possibly returning corrupt data.<br /><br /> My motivation:<br /><br />
Twoyears ago accidentally I opened a discussion on how to do updates to the binary encoding of data in the protocol
[1].I would like to reopen the discussion now since the jsonb 'binary' encoding is just a version '1' + text json. The
resultfrom the last discussion was that having a version or flags as part of the binary format is not enough, since
drivers/libraries(fixable) and applications (unfixable) are depending on the current encoding.<br /> And if we add a
newbit to the flags or bump the version number we will break backward compatibility.<br /><br /> To summarize the
previousdiscussion:<br /> - there are currently no written rules for modifying the binary encoding formats<br /> -
byteamodification was done with a GUC, but GUC was seen as a bad solution in general<br /> - my proposal was to add a
minorformat version number was not good either since any per session state would be problematic for connection
poolers<br/><br /> [1]:
http://grokbase.com/t/postgresql/pgsql-hackers/11bwhv1esa/add-minor-version-to-v3-protocol-to-allow-changes-without-breaking-backwards-compatibility<br
/></div>
