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 | CAFj8pRDho+=hsF3JpnrG0XPzwdGyaeC6XcdvPmGPMKZ_d4sirw@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 15:34 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:
Hello again,So any dynamic created object and related operations are not checkable byplpgsql_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 - but1. 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.
pgsql-hackers by date: