Allow larger column sizes than 8001 in case DB supports it #7000
Conversation
|
|
CT Test Results 2 files 15 suites 3m 45s ⏱️ Results for commit 53ef5df. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
In PostgreSQL, the TEXT field can easily have more than 8001 characters and it does return the actual number. The size == 0 would happen in case of some DBs won't return valid value where we would keep the same behavior as of now. Signed-off-by: Igor Raits <igor@gooddata.com>
ignatenkobrain
force-pushed
the
odbc/text-field-size
branch
from
9757a49 to
53ef5df
Compare
IngelaAndin
added
testing
IngelaAndin
added
the
testing
|
Seems reasonable, I have enabled it in our tests to see that it does not break anything. I guess you have tested that it works? |
|
We are using this patch in production for like 5 years :) sadly no, I'm not aware of simple way how to test it. |
|
As it does not break anything and is not prioritized by Ericsson, we have decided to see this as an improvement worth including even if the test are not improved. |
|
This change has introduced a problem where the ODBC port crashes ( I have been able to confirm this change as being the culprit by applying a patch that reverts the change from the 26.1 release. I can open a separate issue for this problem, if you prefer, but it would be helpful if you could give me some pointers to how to collect more information about the crash. For example, it would be useful to know what SQL query it was executing while it crashed, etc. |
In PostgreSQL, the TEXT field can easily have more than 8001 characters and it does return the actual number. The size == 0 would happen in case of some DBs won't return valid value where we would keep the same behavior as of now.