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.
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.
(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.
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.