Re: syntax error position "CREATE FUNCTION" bug fix

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: syntax error position "CREATE FUNCTION" bug fix
Дата
Msg-id Pine.LNX.4.58.0403191604520.15910@sablons.cri.ensmp.fr
обсуждение исходный текст
Ответ на Re: syntax error position "CREATE FUNCTION" bug fix  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
Dear Tom,

> Attached is a proposed patch that fixes the
> cursor-position-in-CREATE-FUNCTION issue per my earlier suggestion.
>
> The re-parsing of the original command is simplistic but will handle all
> normal cases.
> [...]

That's quite a demonstration;-)

However, I still stick with my "bad" simple idea because the simpler the
better, and also because of the following example:

psql> CREATE OR REPLACE FUNCTION count_tup(TEXT) RETURNS INTEGER AS '
DECLARE
  n RECORD;
BEGIN
  FOR n IN EXECUTE \'SELECT COUNT(*) AS c FRM \' || $1
  LOOP
    RETURN n.c;
  END LOOP;
  RETURN NULL;
END;'
LANGUAGE plpgsql;

psql> SELECT count_tup('pg_shadow');
ERROR:  syntax error at or near "FRM" at character 22
CONTEXT:  PL/pgSQL function "count_tup" line 4 at for over execute statement

As you can notice, the extract is not in the submitted query, so there
is no point to show it there.

Maybe real PL/pgSQL programmers will never have syntax errors with their
SQL stuff.

Thus I really think that the parser should return the processed query,
at least in some cases.

Anyway, have a nice day!

--
Fabien Coelho - coelho@cri.ensmp.fr

В списке pgsql-patches по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads