New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EXECUTE STATEMENT parses the SQL text using wrong charset [CORE3282] #3650
Comments
Modified by: @dyemanovreporter: Dmitry Yemanov [ dimitr ] => John Kilin [ johnkilin ] |
Commented by: @dyemanov Test case: set names win1251; create table TestTable ( insert into TestTable(ParamName, ParamValue) set term ^; create or alter procedure TESTSP execute statement SQLText; set term ;^ -- connect using WIN1251 -- connect using UTF8 |
Commented by: @hvlad EXECUTE STATEMENTS have 5 string parameters which could be affected by this "charset issue" : Should we convert all of them into calling attachment charset ? |
Commented by: John Kilin (johnkilin) Why not? |
Commented by: @hvlad Fix is committed into 2.5 source tree. |
Commented by: @hvlad It seems to me that only query text should be converted into attachment charset because engine assumed that query text is in attachment charset. Other parameters (connection string, user name, role and password) should not be coverted into attachment charset because user should be able to set correct charset manually. New fix is committed. |
Commented by: @hvlad John confirmed fix privately |
Modified by: @hvladstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5.1 [ 10333 ] Fix Version: 3.0 Alpha 1 [ 10331 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: Done successfully Test Details: Confirmed on 2.5.0: get "Malformed string" when connect with cset=utf8. |
Submitted by: John Kilin (johnkilin)
Is duplicated by CORE3313
EXECUTE STATEMENT implementation simply calls the DSQL layer to do its job, but DSQL considers the input SQL text having the connection charset. In EXECUTE STATEMENT, however, the SQL text has the actual charset defined by the appropriate variable descriptor. If it differs from the connection charset and the SQL text contains non-ASCII characters, we get "malformed string" or "cannot transliterate" errors.
The issue can be seen if some procedure using EXECUTE STATEMENT is created in one charset, but called with another charset. Or if the dynamic SQL text is retrieved from a column which charset differs from the connection one.
I doubt it can be fixed for earlier versions (because of the layering issues), but it seems doable for v2.5 and v3.0.
Commits: 8e4755b 0e1ea07 c2963f8
====== Test Details ======
Confirmed on 2.5.0: get "Malformed string" when connect with cset=utf8.
The text was updated successfully, but these errors were encountered: