2016-12-30 14:45 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > Please Pavel, could you avoid citing a whole long mail just for commenting > one point? > > * Why is it so necessary for plpgsql variables to be implemented as >>> persistent entities that are in the catalogs in order for you to >>> achieve the static checking you want to? Is this due to limitations of >>> your approach in plpgsql_check, or more fundamental issues? Explain. >>> >> >> There are few reasons: >> >> 1. plpgsql_check cannot to know a order of calls of functions. >> > > Indeed. > > 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. > > 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. Static variables like Clang static variables are not usable - you would to share content between different functions. > > (2) Then the value of the variable is either the default value (eg NULL) > or the assigned value at points of assignement, which must be a valid value > for the type, otherwise the assignement would have failed. > > (3) If there is only one assignment in the code, then you know that the > variable can only have been assigned a non default value from this point. > Probably nice to have in a security context, but it requires you to be > sure that you have access to all the code... > > (4) For a session boolean, then for code "IF @var IS NOT NULL AND NOT @var > THEN RAISE 'cannot access'; END", in a sequence, then one can prove that > for any pl code after this point in the sequence @var has been previously > assigned to true, otherwise the exception would have been raised. > You are speaking about runtime check.There is not a problem to define some rules for runtime check. What is not possible in your design 1. BEGIN RAISE NOTICE '%', @var; END; Without "execution", you cannot to say if usage of @var is correct or not ok, we can use a DECLARE var DECLARE @var EXTERNAL BEGIN RAISE NOTICE '%', @var; END; ok, I can do static check - but 1. anytime I have to repeat DECLARE statement 2. there is not possible to find typo in DECLARE statement Regards Pavel > > > AFAICS, for "static" session variables the only difference is that the > declaration consistency (1) is slightly more built-in, although you still > have to check that no function DROP/re-CREATE the session variable with a > different type, which is quite close to checking (1) for a dynamic session > variable. > > Other properties (2), (3), (4) are exactly the same. > > 2. [...] 3. >> > > Please could you put your pros & cons in the wiki as well? > > Or don't you want to use it? > > -- > Fabien. >
