Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: [HACKERS] proposal: session server side variables |
| Date | |
| Msg-id | CAFj8pRAS6SGT0_H+LGmdu1vENmjyKOUowX4caouHUtkwB_G=Dg@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Responses |
Re: [HACKERS] proposal: session server side variables
|
| List | pgsql-hackers |
2016-12-30 14:45 GMT+01:00 Fabien COELHO <coelho@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.
pgsql-hackers by date: