CREATE FUNCTION try_0(int4) RETURNS int4 AS '
declare anyv ALIAS FOR $1
Begin
return 1 ;
end;
' LANGUAGE 'plpgsql' ;

- проходит,

SELECT try_0(123) as f;

- parser error at or near ""(#7)

???

Сенькаю, но монопенисно.
это я привел один из вариантов. На самом деле не вызываются все ранее работающие ф-ии 'plpgsql'. Ф-ии sql работают нормально.

Началось с сообщения содержащего пару слов наподобие {overflow}? и {cash}. Сообщение выпало при попытке вызвать некую отлаживаемую ф-ию. Не помню выражения, но смысл ~

try_droptable(text) RETURN boolean AS'
...
begin
IF (SELECT count(*) FROM pg_tables WHERE tablename=$1)>0 THEN
DROP TABLE $1;
RETURN TRUE;
ELSE
RETURN FALSE;
END IF
END;
...

-что -то в этом духе, что съелось но при запуске выдало описанную ругань. Затем я начал сомневаться: 1. не обязательно ли в инструкция DECLARE переобъявлять все параметры, 2. во все ли места plpgsql выражения можно воткнуть "переменные", или, как обычно, только в определенные (конструкции SET values; select [value] as ; сравнения конструкци WHERE/HAVING, и т.п..) (т.е. буквально: окончательная интерпретация выражения производится после всех подстановок, или именно в заданном виде, как выражения с параметрами, которые, в свою очередь, обязаны занимать вполне оперделенные места - именно в силу особенностей интерпретации). Но до проверки в безобидных SELECT (вместо "опасного" DROP) дело не дошло - выдается
parser error at or near "" на все ф-ии, в том числе "образцовые" (и ранее работающие). Такие дела. Как говориться - "один дурак..." :0)

Спасибо, я так и подозревал, что интерпретируется строка до подстановок - т.е. как строка с параметрами. (а не после всех подстановок)

Вопрос: - как оживить интерпретатор plpgsql (чтой то я ему открутил, думается) :0)
Т.е. что посоветовать запустить админу из программной строки? Дропнуть ленгвич и установить по новой? А что будет с функциями?

________
Не в тему: Нашел RAISE, но не нашел RESUME, TRY, ON ERROR и т.п. Этих конструкций просто нет? Т.е. если нужно обработать что -нить с возможностью ветвления при ошибках - это все необходимо организовывать из внешних прилад? А как быть, если все это (обработка ошибок + ветвления) хочется в одной транзакции? Или я что-то пока просмотрел в возможностях plpgsql? (EXECUTE опробую - просто в букваре он встречался только в конструкциях триггеров. При подробном поиске нарыл нужное лирическое отступление:

With the exception of dynamic queries (SQL queries run with the EXECUTE keyword), all PL/pgSQL expressions in a function are only prepared once during the lifetime of the PostgreSQL backend process. Since expressions are only prepared once, constant values (not constant variables, but values such as the now and current timestamp values) used in PL/pgSQL expressions are only prepared once, causing code with constant values that require run-time interpretation to break.

оно-то несколько прояснило ситуацию /раньше-то : - скользнул и не зафиксировался, хотя и помню, что попытался отметить себе в памяти/ :) - еще раз спасибо!

________________
PS:
/PostgreSQL 7.0.2: CREATE OR REPLACE FUNCTION ...
parser error at or near "OR"

REPLACE FUNCTION ...
parser error at or near "REPLACE"

- мдя...

Получил права. ЗАпустил сначала: Попробовал ф-ию (из числа лежащих в букваре) - ответ тот же, что и в теме.
Далее выполнил:
Ответ тот же, что и выше.

!!! Что делать? Кто виноват? Как нам реорганизовать ...?

т.е. ф-ии "компилятся" (наличие языка подтвержадется), в pg_proc попадают, но не выполняются. Начинаю сомневаться, что гонял хоть одну функцию не 'SQL' (plpgsql) на выполнение... но смутно ж помню...