3 ms·
Since compression can produce any bit combination with equal probability, the only way to reliably auto-detect from the contents is to put some kind of fixed fl
by mark-r 5y ago
Since compression can produce any bit combination with equal probability, the only way to reliably auto-detect from the contents is to put some kind of fixed flag at the front. At that point you get more flexibility by making it a new column in the table instead. It doesn't seem like it would be hard to extend this with a compression type and mime type if you need those.
I question the need for multiple compression types though, the difference between the default and the best won't be great enough to be worth the hassle. Especially if it leaves you open to a patent troll.
- edwintorok 5y ago`zstd` and `zlib` as the only 2 supported formats would be enough for me (zstd for state of the art, fast compression and decompression, with choice of high compression ratios if needed; and zlib for backward compatibility/portability), but others may disagree and want their own favourite compression format there. OTOH if you use zstd that already has multiple file capability built-in, so you don't gain much by using sqlite (unless zstd were to adopt sqlite as.its storage format...).
- edwintorok 5y agoActually looks like if you pass multiple files to zstd it'll compress them individually, it won't create an archive, so tar or sqlite format would still be useful there.