Re: proposal: session server side variables

2016-12-29 9:36 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

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

getter/setter functions are implementation in first step. I spoke, so this
step is not last.

>
>
> - 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 disagree - some concepts are more robust, other less.

Regards

Pavel

>
> I have open a wiki page to help with this discussion:
>
> https://wiki.postgresql.org/wiki/Variable_Design
>
> --
> Fabien.
>