Re: proposal: plpgsql pragma statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql pragma statement
Date
Msg-id CAFj8pRBTrhR=WfJh5M_9AX9m6s0KURVwzL2cu9vx7i8_GL4dWA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql pragma statement  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: removal of dangling temp tables
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements