[reporter="jvs", created="Wed, 22 Mar 2006 12:23:49 -0500 (GMT-05:00)"]
The query below demonstrates the problem. (I added the explicit cast to
char(2)
so that the bug can be verified with old broken code which treats string
literals as varchar instead of char.)
The generated code pads the results as if they were char(128). The reason is
that in CalcRexImplementorTableImpl, overlayFunc is registered with
BinaryStringMakeSametypeImplementor, which calls implementConversionIfNeeded,
which combines varchar(128) with char(2) to get char(128), which is just wrong
in this context.
0: jdbc:farrago:> select overlay(name placing cast('??' as char(2)) from 2 for
1) from sales.emps order by 1;
+------------------------------------------------------------------------------+|
EXPR$0
|+------------------------------------------------------------------------------+|
E??ic||
F??ed||
J??hn||
W??lma
|+------------------------------------------------------------------------------+4
rows selected (2.541 seconds)
[reporter="jvs", created="Wed, 22 Mar 2006 12:23:49 -0500 (GMT-05:00)"] The query below demonstrates the problem. (I added the explicit cast to
char(2)
so that the bug can be verified with old broken code which treats string
literals as varchar instead of char.)
The generated code pads the results as if they were char(128). The reason is
that in CalcRexImplementorTableImpl, overlayFunc is registered with
BinaryStringMakeSametypeImplementor, which calls implementConversionIfNeeded,
which combines varchar(128) with char(2) to get char(128), which is just wrong
in this context.
0: jdbc:farrago:> select overlay(name placing cast('??' as char(2)) from 2 for
1) from sales.emps order by 1;
+------------------------------------------------------------------------------+|
EXPR$0
|+------------------------------------------------------------------------------+|
E??ic||
F??ed||
J??hn||
W??lma
|+------------------------------------------------------------------------------+4
rows selected (2.541 seconds)