В письме от вторник, 17 мая 2022 г. 23:01:07 MSK пользователь Tom Lane написал:
Hi! I came to this branch looking for a patch to review, but I guess I would join the discussion instead of reading the code. > >> Yeah - I think we had better reserve the fourth bit pattern for > >> something extensible e.g. another byte or several to specify the > >> actual method, so that we don't have a hard limit of 4 methods. But > >> even with such a system, the first 3 methods will always and forever > >> be privileged over all others, so we'd better not make the mistake of > >> adding something silly as our third algorithm. > > > > In such a situation, would they really end up being properly distinct > > when it comes to what our users see..? I wouldn't really think so. > > It should be transparent to users, sure, but the point is that the > first three methods will have a storage space advantage over others. > Plus we'd have to do some actual work to create that extension mechanism. Postgres is well known for extensiblility. One can write your own implementation of almost everything and make it an extension. Though one would hardly need more than one (or two) additional compression methods, but which method one will really need is hard to say. So I guess it would be much better to create and API for creating and registering own compression method and create build in Zstd compression method that can be used (or optionally not used) via that API. Moreover I guess this API (may be with some modification) can be used for seamless data encryption, for example. So I guess it would be better to make it extensible from the start and use this precious bit for compression method chosen by user, and may be later extend it with another byte of compression method bits, if it is needed. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su
signature.asc
Description: This is a digitally signed message part.
