Re: proposal: plpgsql pragma statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql pragma statement
Дата
Msg-id CAFj8pRCJYAkH9rv89xOxxb3o02fHzxZ1E+tu+A5rZYGFVdDU=Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql pragma statement  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


pá 7. 12. 2018 v 21:28 odesílatel Robert Haas <robertmhaas@gmail.com> napsal:
On Thu, Dec 6, 2018 at 12:28 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> please, can you propose, some what you like?
>
> For my purpose I can imagine PRAGMA on function level with same syntax like PL/SQL - I need to push somewhere some information that I can use for plpgsql_check to protect users against false alarms. The locality in this moment is not too important for me. But I prefer solution that doesn't looks too strange, and is possible just with change plpgsql parser.

Well, I haven't really studied this, but I would assume a
statement-level pragma would look like an annotation of some kind on
that particular statement, e.g.

PRAGMA plpgsql_check (magic pavel stuff goes here) SELECT ...

Rather than a separate statement:

PRAGMA plpgsql_check (magic pavel stuff goes here);
SELECT ...

This might be the wrong idea, I'm not an expert on this or anything.

it looks strange - if we use a Ada like keyword, we should to use Ada like syntax. and it can looks pretty strange if we will think about multiple PRAGMAs.

For my purpose, the function level or block level pragma can be enough - and there maybe will not be a problem, because you, me would to use PL/SQL near syntax.

Regards

Pavel


 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_partition_tree crashes for a non-defined relation
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: extended query protcol violation?