Hi again, > Yes it does for a while now. Until we reach any agreement regarding > questions (1) and (2) personally I don't see the point in submitting > rebased patches. We can continue the discussion but mark the CF entry > as RwF for now it will be helpful.
Sorry, what I actually meant were the following questions: """ Several things occured to me: - Does anyone believe that va_tag should be part of the utf8-like bitmask in order to save a byte or two? - The described approach means that compression dictionaries are not going to be used when data is compressed in-place (i.e. within a tuple), since no TOAST pointer is involved in this case. Also we will be unable to add additional compression algorithms here. Does anyone have problems with this? Should we use the reserved compression algorithm id instead as a marker of an extended TOAST? - It would be nice to decompose the feature in several independent patches, e.g. modify TOAST first, then add compression dictionaries without automatic update of the dictionaries, then add the automatic update. I find it difficult to imagine however how to modify TOAST pointers and test the code properly without a dependency on a larger feature. Could anyone think of a trivial test case for extendable TOAST? Maybe something we could add to src/test/modules similarly to how we test SLRU, background workers, etc. """ Since there was not much activity since then (for 3 months) I don't really see how to process further. -- Best regards, Aleksander Alekseev