Hello again,
So any dynamic created object and related operations are not checkable by
plpgsql_check (or any tool).
NO. Your first sentence does not imply this very general statement.
If you have not unique definition, you cannot to it. There is not
possibility different between typo and decision. We are talking about
static analyze - so code should not be executed - and you don't know
what function will be started first.
Yes, I assure you that I really know how static analysis works... All the
properties I described below may be proved without executing the code,
that was my point...
Some things that I think can be statically proved within a session, that
would cover some security concerns:
(1) For statically named private dynamic variables declared/used at
different points it can be checked without relying on the function order
that all declarations are consistent, i.e. the same type, same default
value if any.
what is "static" private dynamic variable ? You are using new terminology.
They are my session variable, I just spelled out some properties to be
precise about what I am stating, otherwise it is a mess. The name of the
variable is "static" (statically-named), i.e. it is known directly in the
code. However the variable creation and value are "dynamic".
Static variables like Clang static variables are not usable - you would to
share content between different functions.
Sure. I mean static as in "static analysis", i.e. by looking at the code
without executing it, as you put it.
(2) (3) (4) [...]
You are speaking about runtime check.
Not really, I was speaking about properties statically provable, which I
understood was your concern. Now the properties proved may imply a runtime
assumption, for instance that the code has executed without error up to
some point in the program, which is basically impossible to prove
statically.
BEGIN
RAISE NOTICE '%', @var;
END;
Without "execution", you cannot to say if usage of @var is correct or not
It depends about your definition of "correct".
For this very instance it would not matter: if the variable was not
created beforehand, then an error is raised because it does not exist, if
it was created before hand, then an error is raised because that is what
the code is doing... So an error is always raised if the variable is not
right.
ok, we can use a DECLARE var
DECLARE @var EXTERNAL
I do not know what you mean by 'EXTERNAL'.
BEGIN
RAISE NOTICE '%', @var;
END;
ok, I can do static check - but
1. anytime I have to repeat DECLARE statement
Yes, twice in the complete use case: one for the function which checks the
credentials, one for the getter function.
2. there is not possible to find typo in DECLARE statement
It is possible to find "some" typos, depending on the code: you can check
that a variable is both assigned and used somewhere, otherwise it is very
probably a typo. Perl does that *statically*, before executing a script.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
