On 21/05/2021 17:53, Alex Peshkoff via Firebird-devel wrote: > On 5/21/21 9:19 PM, Adriano dos Santos Fernandes wrote: > >>> 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. > > OK. Let's compare what do you obtain with needed for that changes.
Allow reading full blob segments. > Incrementing XSQLDA version is rather serious change in old API which on > the other hand you do not want to improve. I think that there should be > very serious reasons for such change. It's easy and compatible change. > >> >>> 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. > > Half-done solution at the first glance. Full 64Kb appears much more > interesting. Agree - aligned block of memory which size is power of two > is always prefered unit.> Varchar length (actual, not declared) could be between 0-MAX_USHORT (64K possible values). To support max. of 64K bytes, length field must be increased to 32 bits. If that is the solution, then a new descriptor/SQL type should be added. > I once again stop discussing details - let's begin with the beginning, > why is increase of char/varchar important for BLOB utils. Is it alone > interesting enough to change XSQLDA version? > The benefit for the old API is to support large strings. That's a benefit in itself, it has nothing directly to do with RDB$BLOB_UTIL. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
