From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-12-28 15:54:10 |
Message-ID: | CAFj8pRB+ywPwK5ug8ahd0bkW9PC6qmBA=sLiSrySEfCfbQD6uw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-12-28 16:42 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> Hello,
>
> Why should they? If it is a session variable, being created when needed or
>>> used with the right type could be enough?
>>>
>>
>> You cannot to trust some fuzzy object - or you have to play hard game with
>> securing content - hashing, coding, decoding - it is slow, cpu intensive
>>
>
> I'm afraid that I do not understand. I do not think that a hash get in
> memory is particularly costly. I do not see how you could do less that that
> to manage variables with associated values.
>
> Currently the big issue of plpgsql_check is work with temporary tables.
>>>
>>
>> No, I mean so when you use temporary tables inside plpgsql functions, then
>> the static analyze like plpgsql check is almost impossible.
>>
>
> I cannot to speak instead you, but lot of people prefer static analyze of
>> code.
>>
>
> 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.
>
> The static analyze can be done only on static (persistent metadata).
>>
>
> A session variable is a bit like a global temporary variable. A static
> analysis tool could take into account a global temporary variable.
>
> You cannot do it with dynamic (unfixed in schema) objects.
>>
>
> 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 - you have to repeat DECLARE in every function.
What is somebody somewhere write @fooo or use DECLARE @foo integer instead.
There is big space for errors.
Regards
Pavel
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-12-28 15:57:08 | Re: proposal: session server side variables |
Previous Message | Fabien COELHO | 2016-12-28 15:42:28 | Re: proposal: session server side variables |