From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | proposal: plpgsql: special comments that will be part of AST |
Date: | 2021-07-24 05:39:53 |
Message-ID: | CAFj8pRBmQ195e4-1OFh-rY0+BTD5FhROrfUwXUC+VhryMQ308A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
As an author of plpgsql_check, I permanently have to try to solve genetic
problems with the necessity of external information for successful static
validation.
create or replace function foo(tablename text)
returns void as $$
declare r record;
begin
execute format('select * from %I', tablename) into r;
raise notice '%', r.x;
end;
$$ language plpgsql;
On this very simple code it is not possible to make static validation.
Currently, there is no way to push some extra information to source code,
that helps with static analysis, but doesn't break evaluation without
plpgsql_check, and doesn't do some significant slowdown.
I proposed Ada language pragmas, but it was rejected.
I implemented fake pragmas in plpgsql_check via arguments of special
function
PERFORM plpgsql_check_pragma('plpgsql_check: off');
It is working, but it looks bizarre, and it requires a fake function
plpgsql_check_pragma on production, so it is a little bit a dirty solution.
Now, I have another proposal(s).
a) Can we invite new syntax for comments, that will be stored in AST like a
non executing statement?
some like:
//* plpgsql_check: OFF *//
RAISE NOTICE '%', r.x
or second design
b) can we introduce some flag for plpgsql_parser, that allows storing
comments in AST (it will not be default).
so "-- plpgsql_check: OFF " will work for my purpose, and I don't need any
special syntax.
Comments, notes?
Pavel
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-07-24 09:52:01 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
Previous Message | Soumyadeep Chakraborty | 2021-07-24 05:26:17 | Re: A micro-optimisation for ProcSendSignal() |