Hi, I can add this to a list of extensions to the LZF code. It's not a bad idea to have a version which is fully binary compatible, which can be used as a compatibility option in the future.
Hopefully, I can add this once my higher-compression extensions to LZF finish code review (*cough cough*). As it stands, the H2 LZF code outperforms QuickLZ's Java version, when it comes to compression and decompression speeds (although it does not compress as much). I think this part of the project is strong enough that with a few extensions it could stand on its own. Regards, Sam Van Oort On Dec 1, 2:59 pm, Thomas Mueller <[email protected]> wrote: > Hi, > > > True. It would be intrusive change. And since this is not exposed > > outside (I think?), it does not matter all that much. That is, > > compression/decompression is automatically handled by drivers? > > Yes. There is one case where it is exposed: the functions COMPRESS and > EXPAND. If binary compatibility is required, a new compression type > could be added. Currently, I don't think this is required. > > Regards, > Thomas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
