On 5/22/21 12:03 AM, Adriano dos Santos Fernandes wrote:
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.
I do not want to say that it's hard to implement change, but it's
serious change from users POV.
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.
On my mind that's step in wrong direction. We have plans to support type
string, just string - without maximum length, and adding something
intermediary that requires change of XSQLDA version (i.e. format) seems
meaningless. What about reading segments - a way to read them partially
(i.e. completion condition RESULT_SEGMENT) is known since long-long ago.
IMO to enhance old isc API we need something more serious.
One more detail - very ogten, when discussing possible changes in old
API, we used to answer - no, that requires changes in SQLDA. I think we
should follow that way or collect everything we miss in SQLDA and
include it into FB5 but not make API changes due to non-critical need in
other firebird part.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
