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.
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. Please explain what do we win in
blob package with longer char/varchar.
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.
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?
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
