Я тут в очередной раз наткнулся на очень неприятную ситуацию с параметром и полем. Поэтому хочу переговорить в первую очередь с разработчиками FB о ней.
1. Есть таблица, в ней поле, к примеру, ID.


2. Есть ХП, которая получает данные из неё.


Это абсолютно корректная ХП, которая делает то, что надо.
Но, если немного ошибиться, и забыть указать двоеточие у параметра DATE_ACCOUNT, то сервер это скомпилирует и по сути получится условие "A.DATE_ACCOUNT = A.DATE_ACCOUNT". Хорошо, если в таблице более одной записи, то получаешь multiple rows и пытаешься найти причину. Но если в запросе стоит FIRST 1 и ORDER BY, то это можно обнаружить только тогда, когда начинаешь получать несколько не те данные, что ожидаешь.
Бывает другой случай: селект для INSERT или просто селект: должно быть "SELECT ID, :DATE_ACCOUNT FROM ...", а разраб по ошибке пишет "SELECT ID, DATE_ACCOUNT FROM ...".

Вопрос разработчикам - можно ли сделать проверку на то, что если имя поля указано без альяса и есть параметр с таким именем, выдавать про двойственность, по аналогии с "Ambiguous field name"? Или как вариант запретить ссылаться на поле без указания альяса, если у таблицы есть альяс.
Я понимаю, что здесь больше про человеческий фактор, но тем не менее. Я напишу Хвастунову, чтобы он добавил такую проверку в парсере, но не факт, что он будет такое делать. В любом случае, хотелось бы видеть такое непосредственно в сервере.

Ты не понял. Речь про то, что FIELD может оказаться как полем таблицы, так и параметром.
Если нет параметра с именем FIELD (выходного или входного) - считаем, что все ОК.


См. предыдущий ответ.


Собственно, так и делаю. Но стоит пропустить двоеточие перед именем параметра и не увидеть этого...

Возможно. Если другие разрабы поделятся, как у них это сделано и почему именно так, подумаю над этим.
Давным-давно я пробовал вырвиглазные конструкции с префиксами типа "IN_", "OUT_", "V_", "VAR_" и т.д, но это оказалось жутко неудобно как в части написания кода, так и работы с такими ХП.

Кстати, в EXECUTE BLOCK сделана поддержка связывания имен.


Снаружи для все это параметр ID, а внутри - имя такое, какое надо.
В случае ХП такого нету. Поэтому если объявлять вот так:


то выборка получается через "SELECT OUT_ID FROM TEST_SP(1)".

Написать вот так, к сожалению, нельзя:

Предлагаемое ограничение никак на этом не отразится.

Я так и делаю, кроме случаев, когда параметр в левой части - привычка с до-FB3 времен. Но в новых ХП/пакетах или при редактировании старых, если не лень, добавляю.


Отличный вариант.
Суть в том, что глаз замыливается и не всегда удается заметить, что где-то не хватает двоеточия или наоборот, оно не нужно.
Если параметр будет окрашен в другой цвет (а в идеале разный цвет для входных, выходных и переменных), то отсутствие двоеточия будет сразу видно.


Так там и сейчас только переменные.

Спасибо. Нашел "Настройки - Настройки редактора" - Вкладка "Цвет" и Variable. К сожалению, IBExpert не отличает входной и выходной параметр от задекларированной переменной. Хотя то что есть уже хорошо.

Это же очевидно - чтобы глядя на PSQL, сразу понимать, где какой параметр используется. Вот тут выборка по входному, тут присваиваем значение выходному. Когда текст процедуры достаточно большой (с десяток экранов) и не помнишь все параметры, то достаточно посмотреть на FOR SELECT и список его INTO, чтобы увидеть, что все параметры одного цвета и значит, все ОК. То же самое с условиями.

Так за 20 лет я только сейчас сам понял, что окрашивать параметры - хорошая идея, после того как ты предложил такое. Из коробки этого не было, а сам не догадался там правки вносить. Так что это не показатель.

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

А что, разве плохое желание? Другое дело, что практического смысла в этом мало. Потому что не получится соединить таблицу с доменом, сделать выборку из функции или выполнить триггер. Хотя вот визуально отличить таблицу от представления или от процедуры без параметров - мысль интересная.


Да, именно в этом и засада. Поэтому легко опечататься и указать не то, что хотел. Собственно, для этого IDE и предназначена - упростить труд пользователя и помочь ему избежать очевидных или легко выявляемых ошибок.

А это вкусовщина.

Вот, например:


SYS$LINK$MS - это ХП или таблица или представление? Конечно, я узнаю, что это, просто глядя на имя - ведь есть конвенция именования объектов. Но ее иногда приходится нарушать или это Legacy-объект, который сейчас никак не переименовать. А если это новый сотрудник смотрит? Ему надо лезть в объект, смотреть, что это.
А DATE_BEGIN - это переменная или входной параметр? Тоже надо лезть в декларацию, а это двумя экранами выше или кликать на параметре и смотреть подсказку.

Если будет возможность выделить цветом таблицы, пакеты, PSQL-функции, UDF (их особенно), я буду первый, кто это сделает.