Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

Hello again,

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

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

> BEGIN
>  RAISE NOTICE '%', @var;
> END;
>
> ok, I can do static check - but

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

-- 
Fabien.