parser error at or near ""

Пупкин
Дата: 28.08.2003 20:06:31
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)

???
Stellar.
Дата: 29.08.2003 09:33:53

CREATE OR REPLACE FUNCTION try_0(int4) RETURNS int4 AS '
DECLARE
anyv ALIAS FOR $1 ;
BEGIN
return 1 ;
END;
'
LANGUAGE 'plpgsql' ;



не следует забывать ";"
Пупкин
Дата: 29.08.2003 11:13:40
Сенькаю, но монопенисно.
это я привел один из вариантов. На самом деле не вызываются все ранее работающие ф-ии '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)
Stellar.
Дата: 29.08.2003 11:36:38
из коммандной строки:
createlang -U pgsql plpgsql имя_базы


member=# CREATE OR REPLACE FUNCTION try_0(int4) RETURNS int4 AS '
member'
# DECLARE
member'# anyv ALIAS FOR $1 ;
member'
# BEGIN
member'# return 1 ;
member'
# END;
member'# ' LANGUAGE 'plpgsql' ;
CREATE FUNCTION
member=#
member=# select try_0(1);
try_0
-------

1
(1 row)



Все отлично работает.
Stellar.
Дата: 29.08.2003 11:38:36
DROP TABLE $1;
работать не будет.

будет -
EXECUTE ''DROP TABLE '''''' || $1 '''''' ;'';
Пупкин
Дата: 29.08.2003 12:48:33
Спасибо, я так и подозревал, что интерпретируется строка до подстановок - т.е. как строка с параметрами. (а не после всех подстановок)

Вопрос: - как оживить интерпретатор 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"

- мдя...
Пупкин
Дата: 02.09.2003 18:41:45
Получил права. ЗАпустил сначала:

DROP PROCEDURAL LANGUAGE 'plpgsql';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler
LANCOMPILER 'PL/pgSQL';
Попробовал ф-ию (из числа лежащих в букваре) - ответ тот же, что и в теме.
Далее выполнил:
DROP FUNCTION plpgsql_call_handler ();

CREATE FUNCTION plpgsql_call_handler () RETURNS opaque
AS '/usr/local/pgsql/lib/plpgsql.so'
LANGUAGE 'C';

DROP PROCEDURAL LANGUAGE 'plpgsql';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler
LANCOMPILER 'PL/pgSQL';

Ответ тот же, что и выше.

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

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