fb user,

ты в isql проверял? В том числе экспорт в скрипт.
Если там нет ошибок, то да ошибка в IBE.

P.S. На хрена потребовалось включать чувствительность к завершающим пробелам? Тем более по дефолту для всех полей чарсета win1251.
Я бы не назвал это ни хамством ни троллингом. Тебе ответили, что ты сам виноват только и всего.

И таки да. Ты в курсе что это должно адекватно работать только для вновь создаваемых объектов метаданных?

fb user,

Если я правильно понял, то произошло следующее

У rdb$relation_name чарсет UNICODE_FSS для которого ничего не меняли. Однако литерал 'RDB$FIELDS' теперь сравнивается с учётом пробелов. Тип поля rdb$relation_name CHAR(31). Он дополняется пробелами до декларированной длинны. В итоге мы ни хрена не находим.

Ты думаешь нечувствительность к конечным пробелам по умолчанию от балды поставили?

fb user,

читай CREATE COLLATION там это есть. Про косяки которые могут возникнуть с IBE и другими прогами там конечно не написано. Да и грубо говоря это не совсем косяк FB. PAD SPACE по умолчанию стоит потому что это по стандарту, ну и ИХМО так удобнее сравнивать CHAR с VARCHAR. Если где-то нужно другое поведение включаем такое поведение для этого филда. А включать сразу для всей кодировки опасно как оказалось.

fb user,

а ты про сравнение строк и то что там не учитываются завершающие пробелы? Надо посмотреть.

fb user,

согласен про то, что сделано для сравнения CHAR без пробелов. В остальном нет.

Не знаю когда там появились VARCHAR, но скажу так — и тот и другой тип нужен. Просто надо понимать что CHAR лучше использовать для строк фиксированной длины. Есть такие данные где число введённых символов приблизительно одинаковое. Например номер телефона. В таких случаях использование CHAR предпочтительней. А там где оно сильно может разниться лучше использовать VARCHAR (например ФИО).

По какой причине в системных таблицах для объектов метаданных выбран тип CHAR я не знаю. Возможно это обусловлено историческими причинами, но теперь это так и вряд ли это будут переделывать.

Опять про стринги разговоры пошли. NickDee признавайся это ты?

fb user,

да CHAR для строк постоянной длины более удобен. Ты в курсе что VARCHAR требует два дополнительных байта для хранения длины?

fb user,

Не стоит забывать что для CHAR память выделяется один раз и сразу. Просто оставшаяся длина инициализируется пробелами. Оно во многих случаях дешевле. С VARCHAR удобней производить конкатенацию, т.к. не надо задумываться об обрезании пробелов.

Про ФИО.
Я вообще считаю что эти поля здесь не обязательны. Во-первых есть COMMENT для пользователей куда ты хоть целое сочинение можешь написать. Во-вторых есть пользовательские свойства (TAGS), куда можно до 255 символов текста вносить. В-третьих ты можешь создать свою таблицу и завязаться на имя логина и пихать туда что угодно в удобном для себя формате.

Про поле PLUGIN ты судя по всему вообще ничего не понял.
И почему оно должно иметь другую кодировку. Я уже говорил если менять кодировку метаданных, то у всего и сразу. Да UTF-8 был бы предпочтительней, но там без увеличения длины поля не обойтись, а это потянет за собой кучу других переделок. Да и придётся в ресторе снова делать -fix_metadata utf8. Жаль конечно что текст исключения обделили и оставили у него NONE.

И вообще твои выпады какие-то не серьёзные. Не там ты видишь проблемы. Не там.
Поверь большинству пользователей начхать на бесконечные строки и на названия объектов метаданных в национальной кодировке. Их волнуют прежде всего производительность, безопасность, надёжность и языковые возможности. Можно для интереса тему замутить "Что вы хотите видеть в Firebird 4?". Как-то была тут подобная много лет назад. Сразу будет видно приоритет твоих хотелок и что реально хочется большинству.