Currently the criteria on updating the F/B protocol is undefined. This makes it 
hard to update the protocol going forward. It makes it also hard to write 
library/driver/application implementations that will be more future proof to 
future server versions.

Ideally the documentation for 9.4 (backport?) would say what kind of things are 
allowed to change within the v3 protocol, and thus implies what kind of changes 
need a new v4 protocol. Is there some wishlist page of items to do differently 
for v4 already?

I did find the following text in the documentation: "binary representations for 
complex data types might change across server versions". But having more 
specific rules would help, especially since it seems to be there just to scare: 
so far changes have been strongly discouraged.

An example to consider: some binary formats have flags (arrays) or version 
(jsonb) field. We should explicitly say that clients must reject any unknown 
bits/versions that they do not know about. This guarantees they detect small 
format updates instead of silently accepting then and possibly returning 
corrupt data.

My motivation:

Two years 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 result from 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.
And if we add a new bit to the flags or bump the version number we will break 
backward compatibility.

To summarize the previous discussion:
- there are currently no written rules for modifying the binary encoding formats
- bytea modification was done with a GUC, but GUC was seen as a bad solution in 
- my proposal was to add a minor format version number was not good either 
since any per session state would be problematic for connection poolers


Reply via email to