Hi!

Currently max. CHAR length is limited to 32767 and max. VARCHAR to 32765.

I didn't found any blocker prevent raising that limits to 65535 and
65533 respectively.

But I want to raise them both to 65535 to allow read 64KB segments in
RDB$BLOB_UTIL.

To support that, internals must be changed so that the 16-bit dsc_length
variable for dtype_varying does not store +2 (varchar length field)
added to dsc_length, as well not add +1 for dtype_cstring (not sure
about cstrings - more later).

That changes how descriptors are represented internally.

dsc_length is currently the descriptor's physical length. With the
change it will represent a logical length. To support that I added
getPhysicalLength() method to struct dsc returning an unsigned 32-bit
that sums +2/+1 for dtype_varying/dtype_cstring.

blr_varying* already uses the logical length so there is no problem here.

blr_cstring* uses physical length as current dsc_length. So maybe we
should not change how dtype_cstring works.

Most places requiring change is where formats are created, which need to
get length with getPhysicalLength() instead dsc_length. Sort also
requires few changes.

Descriptors are stored in RDB$FORMATS but they are not backed-up and
restored, so that is not a problem. They are recreated on demand. With
the change implemented in minor ODS update, ODS 13.0 must still write
old format descriptors. And when reading formats of ODS 13.0 in new
engine, it must also adjust lengths (decrement stored values after read
in memory).

If this is implemented in minor ODS update, DDL columns limits must also
have the old values in ODS 13.0 databases.

Usage of MAX_VARY_COLUMN_SIZE for fld_ctx_var_value in fields.h must
also be checked.

UDFs by descriptors looks incompatible, so there must be compatibility
logic which will make not possible to use >= 65533/65534
dtype_varying/dtype_cstring with them.

I have almost this working with few defects in TCS.

I will finish the changes and create PR if you think this approach is
acceptable.


Adriano


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to