Обсуждение: proposal: plpgsql pragma statement
Hi
I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stop a analyse, because there are not necessary data.
I see one possible solution in introduction of pragma statement with syntax:
PRAGMA keyword [content to semicolon];
The pragma has a relation to following statement. So the issue 36 can be solved by pragma
PRAGMA cmdtype CREATE;
EXECUTE format('CREATE TABLE xxx ...
The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragma statement. This information can be used by some plpgsql extensions.
What do you think about this proposal?
Regards
Pavel
Hello Pavel, > > The PRAGMA statement does nothing in runtime. It works only in compile > time, and add a pair of key, value to next non pragma statement. This > information can be used by some plpgsql extensions. > > What do you think about this proposal? > You can use PERFORM as a workaround: PERFORM 'PRAGMA', 'cmdtype', 'CREATE'; There's some overhead when executing, but probably not too much. Best regards, Alexey
Hi
st 5. 12. 2018 v 12:42 odesílatel Alexey Bashtanov <bashtanov@imap.cc> napsal:
Hello Pavel,
>
> The PRAGMA statement does nothing in runtime. It works only in compile
> time, and add a pair of key, value to next non pragma statement. This
> information can be used by some plpgsql extensions.
>
> What do you think about this proposal?
>
You can use PERFORM as a workaround:
PERFORM 'PRAGMA', 'cmdtype', 'CREATE';
There's some overhead when executing, but probably not too much.
Thank you for tip, but I have not any idea, how it can work?
Regards
Pavel
Best regards,
Alexey
You can use PERFORM as a workaround:
PERFORM 'PRAGMA', 'cmdtype', 'CREATE';
There's some overhead when executing, but probably not too much.Thank you for tip, but I have not any idea, how it can work?
Well, I thought you were for a comment-like thing that remains there when compiled and can act as a hint for your static analysis extension.
Surely this PERFORM won't impose any hints on the following statement itself.
But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
Best,
Alex
But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
In this case, comment line in some format will be better than real PERFORM statement. Like this:
/*+PRAGMA cmdtype CREATE; */
EXECUTE format('CREATE TABLE xxx ...
----- Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
st 5. 12. 2018 v 14:42 odesílatel Alexey Bashtanov <bashtanov@imap.cc> napsal:
You can use PERFORM as a workaround:
PERFORM 'PRAGMA', 'cmdtype', 'CREATE';
There's some overhead when executing, but probably not too much.Thank you for tip, but I have not any idea, how it can work?
Well, I thought you were for a comment-like thing that remains there when compiled and can act as a hint for your static analysis extension.
Surely this PERFORM won't impose any hints on the following statement itself.
But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
PERFORM is +/- SELECT, so if I use PERFORM, I have to modify this statement.
Best,
Alex
st 5. 12. 2018 v 15:03 odesílatel Pavel Luzanov <p.luzanov@postgrespro.ru> napsal:
But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
In this case, comment line in some format will be better than real PERFORM statement. Like this:
/*+PRAGMA cmdtype CREATE; */
EXECUTE format('CREATE TABLE xxx ...
I though about it, but it is significantly harder for implementation. Now, the content of comments are just ignored. If we push PRAGMA into comments, then we should to do some work with comments.
PRAGMA as statement is much more easy for implementation. But Using PRAGMA inside comments is very good alternative.
Regards
Pavel
----- Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
st 5. 12. 2018 v 15:03 odesílatel Pavel Luzanov <p.luzanov@postgrespro.ru> napsal:
But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
In this case, comment line in some format will be better than real PERFORM statement. Like this:
/*+PRAGMA cmdtype CREATE; */
EXECUTE format('CREATE TABLE xxx ...
I looked there and It is not possible to implement it - plpgsql uses SQL lexer, and the content of comments are just ignored. So I cannot to read comments. There is not any possibility to read it simply from plpgsql. Unfortunately, but it is expected, there is nothing like query string for plpgsql statement.
Regards
Pavel
----- Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
You can alter the lexer and create a comment node, right? That’s how we did hints in EnterpriseDB.
On Wed, Dec 5, 2018 at 11:41 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
st 5. 12. 2018 v 15:03 odesílatel Pavel Luzanov <p.luzanov@postgrespro.ru> napsal:But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
In this case, comment line in some format will be better than real PERFORM statement. Like this:
/*+PRAGMA cmdtype CREATE; */
EXECUTE format('CREATE TABLE xxx ...I looked there and It is not possible to implement it - plpgsql uses SQL lexer, and the content of comments are just ignored. So I cannot to read comments. There is not any possibility to read it simply from plpgsql. Unfortunately, but it is expected, there is nothing like query string for plpgsql statement.RegardsPavel----- Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Jonah H. Harris
Hi
st 5. 12. 2018 v 18:28 odesílatel Jonah H. Harris <jonah.harris@gmail.com> napsal:
You can alter the lexer and create a comment node, right? That’s how we did hints in EnterpriseDB.
I don't think so it is adequate solution - sure, it is, if I would to implement Oracle's hints. But it is not my target. I afraid about performance impacts a) for SQL queries, b) for plpgsql.
I had a possibility to see a functions, procedures (ported from Oracle) with thousands lines of comments. It is not a Oracle problem, due compilation to persistent byte code. But I don't think so this cost is accepted for pragma implementation.
The native plpgsql statement PRAGMA has zero performance impact on existing code. More, the implementation is just local inside plpgsql, what is important for me.
Regards
Pavel
--On Wed, Dec 5, 2018 at 11:41 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:st 5. 12. 2018 v 15:03 odesílatel Pavel Luzanov <p.luzanov@postgrespro.ru> napsal:But maybe your extension could read the PERFORM statement preceding it and treat it as an annotation hint for the following statement.
In this case, comment line in some format will be better than real PERFORM statement. Like this:
/*+PRAGMA cmdtype CREATE; */
EXECUTE format('CREATE TABLE xxx ...I looked there and It is not possible to implement it - plpgsql uses SQL lexer, and the content of comments are just ignored. So I cannot to read comments. There is not any possibility to read it simply from plpgsql. Unfortunately, but it is expected, there is nothing like query string for plpgsql statement.RegardsPavel----- Pavel Luzanov Postgres Professional: http://www.postgrespro.com The Russian Postgres CompanyJonah H. Harris
вт, 4 дек. 2018 г. в 20:13, Pavel Stehule <pavel.stehule@gmail.com>: > > Hi > > I wrote plpgsql_check https://github.com/okbob/plpgsql_check. > > It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stopa analyse, because there are not necessary data. > > https://github.com/okbob/plpgsql_check/issues/36 > > I see one possible solution in introduction of pragma statement with syntax: > > PRAGMA keyword [content to semicolon]; > > The pragma has a relation to following statement. So the issue 36 can be solved by pragma > > PRAGMA cmdtype CREATE; > EXECUTE format('CREATE TABLE xxx ... > > The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragmastatement. This information can be used by some plpgsql extensions. > > What do you think about this proposal? I think it's a good idea in common. But how about multiple PRAGMAs? Consider PRAGMA cmdtype CREATE; PRAGMA objtype TABLE; EXECUTE format('CREATE TABLE');
st 5. 12. 2018 v 19:12 odesílatel Dmitry Igrishin <dmitigr@gmail.com> napsal:
вт, 4 дек. 2018 г. в 20:13, Pavel Stehule <pavel.stehule@gmail.com>:
>
> Hi
>
> I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
>
> It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stop a analyse, because there are not necessary data.
>
> https://github.com/okbob/plpgsql_check/issues/36
>
> I see one possible solution in introduction of pragma statement with syntax:
>
> PRAGMA keyword [content to semicolon];
>
> The pragma has a relation to following statement. So the issue 36 can be solved by pragma
>
> PRAGMA cmdtype CREATE;
> EXECUTE format('CREATE TABLE xxx ...
>
> The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragma statement. This information can be used by some plpgsql extensions.
>
> What do you think about this proposal?
I think it's a good idea in common. But how about multiple PRAGMAs? Consider
PRAGMA cmdtype CREATE;
PRAGMA objtype TABLE;
EXECUTE format('CREATE TABLE');
yes, it is possible. They are assigned to next non pragma statement.
some like
PRAGMA cmdtype SELECT
PRAGMA resulttype (a int, b int, c int)
EXECUTE format('SELECT ... FROM %I ...
PRAGMA tmp_table_query
PRAGMA resulttype (a int, b int, c int)
FOR r IN SELECT * FROM some_temporary_table ...
On Tue, Dec 4, 2018 at 12:13 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > I wrote plpgsql_check https://github.com/okbob/plpgsql_check. > > It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stopa analyse, because there are not necessary data. > > https://github.com/okbob/plpgsql_check/issues/36 > > I see one possible solution in introduction of pragma statement with syntax: > > PRAGMA keyword [content to semicolon]; > > The pragma has a relation to following statement. So the issue 36 can be solved by pragma > > PRAGMA cmdtype CREATE; > EXECUTE format('CREATE TABLE xxx ... > > The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragmastatement. This information can be used by some plpgsql extensions. > > What do you think about this proposal? I think it's commandeering PRAGMA for a fairly narrow purpose. It's hardly unimaginable that someone in future might want a PRAGMA that does change runtime behavior, or that affects something other than the statement which immediately follows. I don't see a big problem allowing some kind of annotation that plpgsql_check can easily access, and I don't even mind it being called PRAGMA. But I don't think it should foreclose unrelated uses of PRAGMA which somebody might want to introduce in the future. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting runtime?
On Thu, Dec 6, 2018 at 11:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Dec 4, 2018 at 12:13 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
>
> It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stop a analyse, because there are not necessary data.
>
> https://github.com/okbob/plpgsql_check/issues/36
>
> I see one possible solution in introduction of pragma statement with syntax:
>
> PRAGMA keyword [content to semicolon];
>
> The pragma has a relation to following statement. So the issue 36 can be solved by pragma
>
> PRAGMA cmdtype CREATE;
> EXECUTE format('CREATE TABLE xxx ...
>
> The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragma statement. This information can be used by some plpgsql extensions.
>
> What do you think about this proposal?
I think it's commandeering PRAGMA for a fairly narrow purpose. It's
hardly unimaginable that someone in future might want a PRAGMA that
does change runtime behavior, or that affects something other than the
statement which immediately follows.
I don't see a big problem allowing some kind of annotation that
plpgsql_check can easily access, and I don't even mind it being called
PRAGMA. But I don't think it should foreclose unrelated uses of
PRAGMA which somebody might want to introduce in the future.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Jonah H. Harris
čt 6. 12. 2018 v 17:27 odesílatel Robert Haas <robertmhaas@gmail.com> napsal:
On Tue, Dec 4, 2018 at 12:13 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
>
> It is working well, but because it does static analyse only, sometimes it can produces false alarms or it should to stop a analyse, because there are not necessary data.
>
> https://github.com/okbob/plpgsql_check/issues/36
>
> I see one possible solution in introduction of pragma statement with syntax:
>
> PRAGMA keyword [content to semicolon];
>
> The pragma has a relation to following statement. So the issue 36 can be solved by pragma
>
> PRAGMA cmdtype CREATE;
> EXECUTE format('CREATE TABLE xxx ...
>
> The PRAGMA statement does nothing in runtime. It works only in compile time, and add a pair of key, value to next non pragma statement. This information can be used by some plpgsql extensions.
>
> What do you think about this proposal?
I think it's commandeering PRAGMA for a fairly narrow purpose. It's
hardly unimaginable that someone in future might want a PRAGMA that
does change runtime behavior, or that affects something other than the
statement which immediately follows.
I don't see a big problem allowing some kind of annotation that
plpgsql_check can easily access, and I don't even mind it being called
PRAGMA. But I don't think it should foreclose unrelated uses of
PRAGMA which somebody might want to introduce in the future.
The most simple (and probably one possible) implementation is plpgsql statement - because I would not to modify SQL lexer.
I am thinking so PRAGMA statement is natural due semantic and usage in Ada, but I am opened any proposals.
Regards
Pavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris <jonah.harris@gmail.com> wrote: > IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting runtime? Well, I don't know what Ada does with PRAGMA exactly, but look at these examples from Oracle: http://psoug.org/definition/pragma.htm You wouldn't *execute* those at runtime, but at least for some of them, the runtime behavior would depend on whether or not they were specified. It certainly seems possible that we might want to have similar things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Ahh. Gotcha. Makes sense.
On Thu, Dec 6, 2018 at 11:57 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris <jonah.harris@gmail.com> wrote:
> IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting runtime?
Well, I don't know what Ada does with PRAGMA exactly, but look at
these examples from Oracle:
http://psoug.org/definition/pragma.htm
You wouldn't *execute* those at runtime, but at least for some of
them, the runtime behavior would depend on whether or not they were
specified. It certainly seems possible that we might want to have
similar things.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Jonah H. Harris
čt 6. 12. 2018 v 17:57 odesílatel Robert Haas <robertmhaas@gmail.com> napsal:
On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris <jonah.harris@gmail.com> wrote:
> IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting runtime?
Well, I don't know what Ada does with PRAGMA exactly, but look at
these examples from Oracle:
http://psoug.org/definition/pragma.htm
You wouldn't *execute* those at runtime, but at least for some of
them, the runtime behavior would depend on whether or not they were
specified. It certainly seems possible that we might want to have
similar things.
My proposal doesn't block it.
The pragma in Ada has three levels - function, block, statement. I propose (in this moment) just statement level syntax, but I am sure, so other levels are possible.
I would to have a autonomous functions or autonomous blocks too, and Ada syntax (same with PL/SQL) is good.
Regards
Pavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
čt 6. 12. 2018 v 18:05 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
čt 6. 12. 2018 v 17:57 odesílatel Robert Haas <robertmhaas@gmail.com> napsal:On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris <jonah.harris@gmail.com> wrote:
> IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting runtime?
Well, I don't know what Ada does with PRAGMA exactly, but look at
these examples from Oracle:
http://psoug.org/definition/pragma.htm
You wouldn't *execute* those at runtime, but at least for some of
them, the runtime behavior would depend on whether or not they were
specified. It certainly seems possible that we might want to have
similar things.My proposal doesn't block it.The pragma in Ada has three levels - function, block, statement. I propose (in this moment) just statement level syntax, but I am sure, so other levels are possible.
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.
I would to have a autonomous functions or autonomous blocks too, and Ada syntax (same with PL/SQL) is good.RegardsPavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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 fromthis 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
č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.
Regards
Pavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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 informationthat I can use for plpgsql_check to protect users against false alarms. The locality in this moment is not tooimportant 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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
č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, ..
Regards
Pavel
RegardsPavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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 sectionDECLAREpragma 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
RegardsPavelRegardsPavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения
On 06/12/2018 18:27, Pavel Stehule wrote: > 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. When you are about to warn about a particular statement, you have the statement's line number, so you can look up the source code and check for any disable-this-warning comments. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pá 4. 1. 2019 v 14:07 odesílatel Peter Eisentraut <peter.eisentraut@2ndquadrant.com> napsal:
On 06/12/2018 18:27, Pavel Stehule wrote:
> 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.
When you are about to warn about a particular statement, you have the
statement's line number, so you can look up the source code and check
for any disable-this-warning comments.
It means to write own lexer and preparse source code before I start checking.
I think so block level PRAGMA is significantly better solution
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jan 04, 2019 at 02:17:49PM +0100, Pavel Stehule wrote: > It means to write own lexer and preparse source code before I start > checking. > > I think so block level PRAGMA is significantly better solution Please note that the latest patch is failing to apply, so I have moved the patch to next CF, waiting on author. -- Michael
Вложения
Hi,
po 4. 2. 2019 v 6:10 odesílatel Michael Paquier <michael@paquier.xyz> napsal:
On Fri, Jan 04, 2019 at 02:17:49PM +0100, Pavel Stehule wrote:
> It means to write own lexer and preparse source code before I start
> checking.
>
> I think so block level PRAGMA is significantly better solution
Please note that the latest patch is failing to apply, so I have moved
the patch to next CF, waiting on author.
attached rebased patch
thank you for checking.
Regards
Pavel
--
Michael
Вложения
On 2/4/19 8:12 PM, Pavel Stehule wrote: > > attached rebased patch This patch has gone through a few iterations but I don't think there's any agreement on what it should look like. There's been no code review that I can see. I think this should be pushed to PG13 at the least, perhaps returned with comment or rejected. Regards, -- -David david@pgmasters.net
Hi
čt 7. 3. 2019 v 8:03 odesílatel David Steele <david@pgmasters.net> napsal:
On 2/4/19 8:12 PM, Pavel Stehule wrote:
>
> attached rebased patch
This patch has gone through a few iterations but I don't think there's
any agreement on what it should look like. There's been no code review
that I can see.
I think this should be pushed to PG13 at the least, perhaps returned
with comment or rejected.
This patch is in this moment in this form interesting just for plpgsql_check's users.
I cannot to move forward without this functionality .. I have a promise of review by some people from big company that uses plpgsql_check, but if there is not interest from commiter's side, then it is not time for pushing this patch today.
On second hand, the proposed syntax is same like for autonomous transactions, so I believe, so this patch will come in few years.
Please, wait few week, and then it can be rejected.
Regards
Pavel
Regards,
--
-David
david@pgmasters.net
On 3/7/19 3:19 AM, Pavel Stehule wrote: > Hi > > čt 7. 3. 2019 v 8:03 odesílatel David Steele <david@pgmasters.net > <mailto:david@pgmasters.net>> napsal: > > On 2/4/19 8:12 PM, Pavel Stehule wrote: > > > > attached rebased patch > > This patch has gone through a few iterations but I don't think > there's > any agreement on what it should look like. There's been no code > review > that I can see. > > I think this should be pushed to PG13 at the least, perhaps returned > with comment or rejected. > > > This patch is in this moment in this form interesting just for > plpgsql_check's users. > > I cannot to move forward without this functionality .. I have a > promise of review by some people from big company that uses > plpgsql_check, but if there is not interest from commiter's side, then > it is not time for pushing this patch today. > > On second hand, the proposed syntax is same like for autonomous > transactions, so I believe, so this patch will come in few years. > > Please, wait few week, and then it can be rejected. > > I have looked at the latest patch, but it seems inadequate unless I'm misreading it. I think a general pragma mechanism should allow a pragma just about anywhere. If the processor doesn't recognize the pragma it ignores it, if it does it processes it in the appropriate context. That could be for the next statement, the current block, or whatever. If it appears in the wrong context the processor should object. For example, one of Ada's predefined pragmas is PAGE, which causes a processor producing a program listing to emit a page feed. (Yes, I know, probably silly, but you get the idea why this pragma can accur just about anywhere.) There is also 'pragma Assert' which is more or less like our Assert in C. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
čt 7. 3. 2019 v 14:40 odesílatel Andrew Dunstan <andrew.dunstan@2ndquadrant.com> napsal:
On 3/7/19 3:19 AM, Pavel Stehule wrote:
> Hi
>
> čt 7. 3. 2019 v 8:03 odesílatel David Steele <david@pgmasters.net
> <mailto:david@pgmasters.net>> napsal:
>
> On 2/4/19 8:12 PM, Pavel Stehule wrote:
> >
> > attached rebased patch
>
> This patch has gone through a few iterations but I don't think
> there's
> any agreement on what it should look like. There's been no code
> review
> that I can see.
>
> I think this should be pushed to PG13 at the least, perhaps returned
> with comment or rejected.
>
>
> This patch is in this moment in this form interesting just for
> plpgsql_check's users.
>
> I cannot to move forward without this functionality .. I have a
> promise of review by some people from big company that uses
> plpgsql_check, but if there is not interest from commiter's side, then
> it is not time for pushing this patch today.
>
> On second hand, the proposed syntax is same like for autonomous
> transactions, so I believe, so this patch will come in few years.
>
> Please, wait few week, and then it can be rejected.
>
>
I have looked at the latest patch, but it seems inadequate unless I'm
misreading it. I think a general pragma mechanism should allow a pragma
just about anywhere. If the processor doesn't recognize the pragma it
ignores it, if it does it processes it in the appropriate context. That
could be for the next statement, the current block, or whatever. If it
appears in the wrong context the processor should object.
For example, one of Ada's predefined pragmas is PAGE, which causes a
processor producing a program listing to emit a page feed. (Yes, I know,
probably silly, but you get the idea why this pragma can accur just
about anywhere.) There is also 'pragma Assert' which is more or less
like our Assert in C.
a PRAGMA can be used on three levels (related to Postgres): function, block, line (and on package on Ada and PLpgSQL). Any PRAGMA has a scope related to usage.
My first patch implemented all levels, but If I understand it well, Tom has strong disagreement with line's level.
So I reduced it just for block level - it is good enough for plpgsql_check, and it is good enough for future autonomous transactions. Other levels can be very simply supported, but I don't need it, and in this moment, I had not a case for it.
For plpgsql_check I need to read some non code informations like: disable, enable some checks, assign some type to record variable, assign some informations about dynamic SQL, ... I think so PRAGMA is very natural tool for this purpose.
My implementation of PRAGMA in this moment just push some tag and some information to AST. It ensure correct syntax. It doesn't do more. But it is good enough for plpgsql_check.
Regards
Pavel
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/7/19 11:45 AM, Pavel Stehule wrote: > > > > > I have looked at the latest patch, but it seems inadequate unless I'm > misreading it. I think a general pragma mechanism should allow a > pragma > just about anywhere. If the processor doesn't recognize the pragma it > ignores it, if it does it processes it in the appropriate context. > That > could be for the next statement, the current block, or whatever. > If it > appears in the wrong context the processor should object. > > > For example, one of Ada's predefined pragmas is PAGE, which causes a > processor producing a program listing to emit a page feed. (Yes, I > know, > probably silly, but you get the idea why this pragma can accur just > about anywhere.) There is also 'pragma Assert' which is more or less > like our Assert in C. > > > a PRAGMA can be used on three levels (related to Postgres): function, > block, line (and on package on Ada and PLpgSQL). Any PRAGMA has a > scope related to usage. > > My first patch implemented all levels, but If I understand it well, > Tom has strong disagreement with line's level. > > So I reduced it just for block level - it is good enough for > plpgsql_check, and it is good enough for future autonomous > transactions. Other levels can be very simply supported, but I don't > need it, and in this moment, I had not a case for it. > > For plpgsql_check I need to read some non code informations like: > disable, enable some checks, assign some type to record variable, > assign some informations about dynamic SQL, ... I think so PRAGMA is > very natural tool for this purpose. > > My implementation of PRAGMA in this moment just push some tag and some > information to AST. It ensure correct syntax. It doesn't do more. But > it is good enough for plpgsql_check. > > That seems pretty brain-dead, TBH. The other thing that bugs me a bit about the patch is that the only testing it does it to make sure that pragmas are ignored by the core plpgsql processor. Maybe that's enough, but mostly we tend to like to have one actual use of a feature. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan <andrew.dunstan@2ndquadrant.com> napsal:
On 3/7/19 11:45 AM, Pavel Stehule wrote:
>
>
>
>
> I have looked at the latest patch, but it seems inadequate unless I'm
> misreading it. I think a general pragma mechanism should allow a
> pragma
> just about anywhere. If the processor doesn't recognize the pragma it
> ignores it, if it does it processes it in the appropriate context.
> That
> could be for the next statement, the current block, or whatever.
> If it
> appears in the wrong context the processor should object.
>
>
> For example, one of Ada's predefined pragmas is PAGE, which causes a
> processor producing a program listing to emit a page feed. (Yes, I
> know,
> probably silly, but you get the idea why this pragma can accur just
> about anywhere.) There is also 'pragma Assert' which is more or less
> like our Assert in C.
>
>
> a PRAGMA can be used on three levels (related to Postgres): function,
> block, line (and on package on Ada and PLpgSQL). Any PRAGMA has a
> scope related to usage.
>
> My first patch implemented all levels, but If I understand it well,
> Tom has strong disagreement with line's level.
>
> So I reduced it just for block level - it is good enough for
> plpgsql_check, and it is good enough for future autonomous
> transactions. Other levels can be very simply supported, but I don't
> need it, and in this moment, I had not a case for it.
>
> For plpgsql_check I need to read some non code informations like:
> disable, enable some checks, assign some type to record variable,
> assign some informations about dynamic SQL, ... I think so PRAGMA is
> very natural tool for this purpose.
>
> My implementation of PRAGMA in this moment just push some tag and some
> information to AST. It ensure correct syntax. It doesn't do more. But
> it is good enough for plpgsql_check.
>
>
That seems pretty brain-dead, TBH.
The other thing that bugs me a bit about the patch is that the only
testing it does it to make sure that pragmas are ignored by the core
plpgsql processor. Maybe that's enough, but mostly we tend to like to
have one actual use of a feature.
Unfortunately plpgsql_check is not part of upstream
I can to write some simple extension - some print tracing, that can use this feature?
Pavel
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/7/19 12:41 PM, Pavel Stehule wrote: > > > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan > <andrew.dunstan@2ndquadrant.com > <mailto:andrew.dunstan@2ndquadrant.com>> napsal: > > > > > The other thing that bugs me a bit about the patch is that the only > testing it does it to make sure that pragmas are ignored by the core > plpgsql processor. Maybe that's enough, but mostly we tend to like to > have one actual use of a feature. > > > Unfortunately plpgsql_check is not part of upstream > > https://github.com/okbob/plpgsql_check > > I can to write some simple extension - some print tracing, that can > use this feature? > > Works for me. Another idea I had was some sort of crypto signature pragma. I still think making it block level only is unwarranted, though. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan <andrew.dunstan@2ndquadrant.com> napsal:
On 3/7/19 12:41 PM, Pavel Stehule wrote:
>
>
> čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> napsal:
>
>
>
>
> The other thing that bugs me a bit about the patch is that the only
> testing it does it to make sure that pragmas are ignored by the core
> plpgsql processor. Maybe that's enough, but mostly we tend to like to
> have one actual use of a feature.
>
>
> Unfortunately plpgsql_check is not part of upstream
>
> https://github.com/okbob/plpgsql_check
>
> I can to write some simple extension - some print tracing, that can
> use this feature?
>
>
Works for me. Another idea I had was some sort of crypto signature pragma.
I still think making it block level only is unwarranted, though.
for me it is better than nothing, and it is good - it is not bad compromise. It can be enhanced in future, when there will be good case. I didn't propose any syntax, feature, that block future full implementation compatible with Ada and PL/SQL.
Pavel
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan <andrew.dunstan@2ndquadrant.com> napsal:
On 3/7/19 12:41 PM, Pavel Stehule wrote:
>
>
> čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> napsal:
>
>
>
>
> The other thing that bugs me a bit about the patch is that the only
> testing it does it to make sure that pragmas are ignored by the core
> plpgsql processor. Maybe that's enough, but mostly we tend to like to
> have one actual use of a feature.
>
>
> Unfortunately plpgsql_check is not part of upstream
>
> https://github.com/okbob/plpgsql_check
>
> I can to write some simple extension - some print tracing, that can
> use this feature?
>
>
Works for me. Another idea I had was some sort of crypto signature pragma.
Here is pragma patch with demo
Regards
Pavel
I still think making it block level only is unwarranted, though.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
so 9. 3. 2019 v 22:17 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan <andrew.dunstan@2ndquadrant.com> napsal:
On 3/7/19 12:41 PM, Pavel Stehule wrote:
>
>
> čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> napsal:
>
>
>
>
> The other thing that bugs me a bit about the patch is that the only
> testing it does it to make sure that pragmas are ignored by the core
> plpgsql processor. Maybe that's enough, but mostly we tend to like to
> have one actual use of a feature.
>
>
> Unfortunately plpgsql_check is not part of upstream
>
> https://github.com/okbob/plpgsql_check
>
> I can to write some simple extension - some print tracing, that can
> use this feature?
>
>
Works for me. Another idea I had was some sort of crypto signature pragma.Here is pragma patch with demo
fixed check-world
Regards
Pavel
RegardsPavel
I still think making it block level only is unwarranted, though.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
Hi Pavel, On 3/10/19 8:39 PM, Pavel Stehule wrote: > Here is pragma patch with demo We're still not getting real review for this patch and Andrew seems as skeptical as anyone that this is the right way to go. I'm planning to mark it as rejected at the end of this CF. Regards, -- -David david@pgmasters.net
po 25. 3. 2019 v 8:38 odesílatel David Steele <david@pgmasters.net> napsal:
Hi Pavel,
On 3/10/19 8:39 PM, Pavel Stehule wrote:
> Here is pragma patch with demo
We're still not getting real review for this patch and Andrew seems as
skeptical as anyone that this is the right way to go.
I'm planning to mark it as rejected at the end of this CF.
I hope so Andrew will have some time to review this patch
Regards
Pavel
Regards,
--
-David
david@pgmasters.net
Hi Pavel, On 3/25/19 3:50 AM, Pavel Stehule wrote: > po 25. 3. 2019 v 8:38 odesílatel David Steele <david@pgmasters.net > <mailto:david@pgmasters.net>> napsal: > > On 3/10/19 8:39 PM, Pavel Stehule wrote: > > Here is pragma patch with demo > We're still not getting real review for this patch and Andrew seems as > skeptical as anyone that this is the right way to go. > > I'm planning to mark it as rejected at the end of this CF. > > > I hope so Andrew will have some time to review this patch As discussed above, I have marked this patch as rejected. It appears that a more general purpose approach is required to get a consensus on this feature. Regards, -- -David david@pgmasters.net
Hi
út 9. 4. 2019 v 15:03 odesílatel David Steele <david@pgmasters.net> napsal:
Hi Pavel,
On 3/25/19 3:50 AM, Pavel Stehule wrote:
> po 25. 3. 2019 v 8:38 odesílatel David Steele <david@pgmasters.net
> <mailto:david@pgmasters.net>> napsal:
>
> On 3/10/19 8:39 PM, Pavel Stehule wrote:
> > Here is pragma patch with demo
> We're still not getting real review for this patch and Andrew seems as
> skeptical as anyone that this is the right way to go.
>
> I'm planning to mark it as rejected at the end of this CF.
>
>
> I hope so Andrew will have some time to review this patch
As discussed above, I have marked this patch as rejected. It appears
that a more general purpose approach is required to get a consensus on
this feature.
I have to accepted this decision. I cannot to write this patch more general - it's absolute generic (or I didn't understand objections).
I agree so now, there are higher priorities, and there are not customers for this patch. But from syntax, semantic perspective, this patch is correct. Now, it is interesting for plpgsql_check users, and their voice was not here, unfortunately. I cannot do more in this area.
Regards
Pavel
Regards,
--
-David
david@pgmasters.net