Re: [HACKERS] proposal: session server side variables

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.