On 5/21/21 3:49 PM, Adriano dos Santos Fernandes wrote:
On 21/05/2021 08:33, Dimitry Sibiryakov wrote:
21.05.2021 09:38, Alex Peshkoff via Firebird-devel wrote:
Any idea how to avoid that?
Redeclare it as unsigned right now.
Yes.
But would be very bad to see not recompiled programs just crashing (or
in infinite loop) if greater length is returned.
So I think we must also create SQLDA_VERSION2 and raise error with
length > 32767 with SQLDA_VERSION1.
Just to make sure - raise error on prepare or when actual length > 32767?
And if we do change SQLDA_VERSION it's worth changing something else in
it. For example - make all sizes uint32, add separate field for charset,
may be something else?
If we increase sizes - let me return to your initial email.
But I want to raise them both to 65535 to allow read 64KB segments in
RDB$BLOB_UTIL.
65535 is 64KB - 1
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).
We have one more unused value for size - zero, we do not support
characters with length == 0.
We may store logical data length - 1, this will make it possible to have
exactly 64Kb fields, which (I believe) can be useful in some cases.
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.
During such cleanup may be make DSC fields private?
What;s also worth taking into an account - what to do if user tries to
include such huge field in an index.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
