ПаWWWлОдАрЕц,

Потому что plpgsql - это не встроенный язык для хранимых процедур, а расширение.
Т.е. он на равных правах, что например C\C++, python, java и прочие внешние ЯП.
Сделан для "совместимости" с PLSQL.
А так нативные ЯП для ХП в PostgreSQL это SQL. :-)

ПаWWWлОдАрЕцmad_nazgul,

Спасибо за ответ.
Я тоже так подумал что это плата за универсальность использования нескольких языков для функций, но я предположил что ноги растут от того, что встроенный plpgsql похож на интерпретируемые языки (like php), и в связи с этим он так "снисходительно" относится к необъявленным переменным.

Хотя, это не дает ему основания игнорировать переменные, ИМХО.


Он и не игнорирует.
Просто вызов интерпретатора происходит не во время создания ХП, а во время выполнения.
А так ну какой-то текст, который должен обработать какой-то внешний обработчик.
Понятно это не удобно.
Но у команды PostgreSQL в приоритете немного другие задачи.

ПаWWWлОдАрЕцПорой обычного SQL не хватает для обработки данных и приходится писать большие простыни кода на plpgsql, и вот как раз эта особенность, очень усложняет отладку кода.


Честно с трудом представляю, что не может оператор with, чтобы использовать plpgsql.

ПаWWWлОдАрЕцА как вы "боретесь" с такой проблемой? Если конечно она вас тоже не обходит стороной )

Никак.
Если что-то нельзя сделать запросом, пишу логику в другом ЯП (java).
Т.е. если есть возможность не пользоваться plpgsql, то лучше им не пользоваться. :-)

p2.mad_nazgulпишу логику в другом ЯП (java).Несомненно, от замены одинарных кавычек на двойные код проблема проверки при компиляции тут же испаряется.

Да.
Т.к. у java (например) есть куча удобных инструментов для работы с кодом.
Что не могу сказать для plpgsql.
Поэтому если нужно написать логику, которая не может быть сделана с помощью SQL, то предпочитаю взять более удобный инструмент, по возможности конечно.