On 21/05/2021 11:51, Alex Peshkoff via Firebird-devel wrote: > 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? >
In isc_dsql_describe / isc_dsql_describe_bind. > 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? > My aim is to increase CHAR/VARCHAR lengths. I think there is no real benefit in improve the old API when the new one already exists and support that. > 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 > Sorry, I mean MAX_USHORT. >> >> 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. > Not possible. >> 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. > We already have this problem: SQL> create table t (c varchar(32765)); SQL> create index t_c on t (c); Statement failed, SQLSTATE = 42000 unsuccessful metadata update -CREATE INDEX T_C failed -key size too big for index T_C Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
