1.
2.
3.
select lpad('1', 3, '0') from rdb$database -- возращает varchar(3)
select lpad('1', 2+1, '0') from rdb$database -- возращает varchar(32765)
select lpad('1', :a, '0') from rdb$database -- возращает varchar(32765)
Проблема ровно одна: движку нужно заранее знать какого размера выделять буфер. Верней не так... Работа с памятью в движке на сегодня устроена так, что требует не только указывать длину строковых полей в БД, но и имеет некоторые другие неудобные архитектурные последствия.
Пока не будет придумана и реализована эффективная работа с резиновым varchar, придётся считаться с некоторыми ограничениями и несуразностями. В delphi например есть оба типа, string(N) и string, причём второй со счётчиком ссылок. И работает всё крайне быстро (например при присваивании одной переменной в другую (или при передаче string-параметра в функцию) не происходит выделения памяти под строку и копирования данных, а происходит лишь увеличение на 1 счётчика ссылок).
В firebird же, насколько я понимаю, при присваивании и передаче в функцию всегда происходит alloc(+zero_allocated_memory)+move.
Всё это сказывается на отжоре памяти и тактах cpu, например при:
1.
select d from (select lpad('1', 2+1, '0') d from rdb$types a, rdb$types b, rdb$types c rows 10000) order by 1
будут выделены и перелопачены лишние мегабайты памяти, причём не только при самом селекте, но и при сортировке. Хотя тут достаточно одного стринга длиной 3 байта, и счётчика ссылок на него.
