Re: proposal: plpgsql pragma statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql pragma statement
Дата
Msg-id CAFj8pRBTrhR=WfJh5M_9AX9m6s0KURVwzL2cu9vx7i8_GL4dWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql pragma statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Hi

st 12. 12. 2018 v 9:03 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:


čt 6. 12. 2018 v 18:27 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:


čt 6. 12. 2018 v 18:17 odesílatel Robert Haas <robertmhaas@gmail.com> napsal:
On Thu, Dec 6, 2018 at 12:13 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> My idea about plpgsql PRAGMA is very close to PL/SQL or Ada PRAGMA. This is not runtime statement - the information from this command will be assigned to related object - function, block, command at parser time.

That's sensible, but the syntax you were proposing didn't look like it
was related to a specific statement.  I was objecting to the idea that
PRAGMA whatever; should be construed as an annotation of,
specifically, the following statement.

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.

I looked to some documentation - and for example - the PL/SQL PRAGMA inline looks very similar to what I propose.

For me good enough is block level pragma used in DECLARE section

DECLARE
  pragma plpgsql_check(OFF);
BEGIN
  .. this part will not be checked ..
END;

The syntax will be prepared for future PL/SQL pragmas like AUTONOMOUS_TRANSACTION, ..

here is block only level PRAGMA - available only from DECLARE part.

The informations are attached to PLpgSQL_stmt_block as List's field pragmas;

Note, if somebody will write support for autonomous transactions, then then the PL/SQL syntax will be prepared. But my motivation is primary for some possibility to push some parameters to plpgsql extensions with user friendly persistent natural readable way.

Regards

Pavel
 

Regards

Pavel 

Regards

Pavel


--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: removal of dangling temp tables
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements