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

From Pavel Stehule
Subject Re: proposal: plpgsql pragma statement
Date
Msg-id CAFj8pRCJYAkH9rv89xOxxb3o02fHzxZ1E+tu+A5rZYGFVdDU=Q@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql pragma statement  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_partition_tree crashes for a non-defined relation
Next
From: Tatsuo Ishii
Date:
Subject: Re: extended query protcol violation?