EXECUTE STATEMENT parses the SQL text using wrong charset [CORE3282] #3650
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.
====== 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:
Commented by: @dyemanov
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
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.