> > 1) Is an in-place LOB different from VARBINARY? Does it - like a > non-in-place LOB - require additional read operation? > In-place BLOBs are similar to BINARY VARYING and in-place CLOBs are similar to CHARACTER VARYING in terms of their storage, but they use API of LOBs. You can set MAX_LENGTH_INPLACE_LOB to a large enough value, change your data types to BLOB (CLOB) and use the LOB API for them for now. Too large values of MAX_LENGTH_INPLACE_LOB setting may be rejected or silently ignored in the future, but most likely only when the issue 1808 will be fixed, because we need a some workaround for it.
> 2) The LOB issue you mention looks like a stopper to me. Since large > BINARY / VARBINARY works fine and do not cause OOM problems (at least in > specific scenarios) would it be possible to add a new URL option that > allows customization of the size limit for VARBINARY columns? We decided to make this limit not configurable. This limit is already very large, usually DBMS have smaller limits for binary and character strings, such as 64K or even 4K. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/96a45919-2d56-4f72-ac81-d323eda3746co%40googlegroups.com.
