|
this example is working:
select lpad('123', 8, '0') || ' string ' || lpad('1240', 8, '0') col from rdb$database In theory, we can know the size, when it's constant.
But actually, this violates complete the layering, and is not supported with current code. Workaround is to cast the result to a varchar of know size: select cast(lpad('xxx', 8, '0') as varchar(8)) one, cast(lpad('yyy', 8, '0') as varchar(8)) two from rdb$database; Adriano, should we consider SUBSTRING as also violating the layering? :-)
Here is what I've replied to Claudio:
> Hello, I read your explanation here > http://tracker.firebirdsql.org/browse/CORE-1346 > In theory, we can know the size, when it's constant. > But actually, this violates complete the layering, and is not supported with > current code. > > Won't substring violate the layering, too? It works with the size of the > field. Initially, I made it to adjust the result to the length parameter, > but this was against the standard. And I supposed it was removed? > However, I don't remember any technical > problem to make it work with the field and the constant length. The problem > was simply the logic was not in the SQL specification. When things go to DataTypeUtil and SysFunction, we don't have access to the constant. My idea when creating these files was to make code compatible with DSQL and JRD. But the problem with PAD is that it can return strings with greater length than the original one, different from SUBSTRING. Backported to 2.1.4.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We don't support return strings of variable length, it needs a maximum size.
When you use two LPAD, another FB limit is reached.