Hello Pavel,
>> Hmmm... I know a little bit about that field, ISTM that you are speaking
>> of the current capabilities of a particular static analysis tool, but I'm
>> not sure that the tool capabilities could not be enhanced to manage more
>> things.
>
> It cannot be - the static analyze is limited to function scope - in static
> analyze you don't know a order of calls.
I have been doing interprocedural static analysis for the last 25 years,
and I can assure you that those techniques are not limited to the scope of
a function. As for global variables, I agree that you may proove more
things about them if you know the order of calls.
>> The private session variables I suggested have a fixed (static) name, and
>> their type could be infered by a static analysis tool, eg:
>> ...
>> DECLARE @foo BOOLEAN PRIVATE;
>> -- I know that there is private a boolean variable "@foo" of unknown
>> value
>> SET @foo = TRUE;
>> --- I know that @foo is true...
>> ...
>
> This is not too friendly
Friendly is subjective. ISTM That it gets the job done with minimal syntax
and implementation. It avoids getter/setter functions which are unfriendly
to me.
> - you have to repeat DECLARE in every function.
That is the same in nearly all programming languages, you have to declare
external variables somehow before using them, that is life.
Some declarations could be avoided if an unknown variable is assumed to
have untyped value NULL by default.
> What is somebody somewhere write @fooo
NULL ? Unkown variable error ?
> or use DECLARE @foo integer instead.
It would not matter if it is someone else, because @foo would be their
private version. If it is yourself, an error could be raised if a session
variable is found to be declared with two distinct types. A static
analysis tool would be able to detect that as well.
> There is big space for errors.
Whatever the features and syntax, you can always shoot yourself in the
foot.
I have open a wiki page to help with this discussion:
https://wiki.postgresql.org/wiki/Variable_Design
--
Fabien.
