2016-12-30 15:34 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > 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'.
it means "used as shared in session" > > > 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. "Before execution" .. I am speaking "without execution". theoretically, if you check all possible functions, you can find some issues - but you have to check all function on server. Elsewhere you cannot to find typo in DECLARE statement. Regards Pavel > > > -- > Fabien. >
