В письме от вторник, 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