Re: [HACKERS] proposal: session server side variables

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.

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

-- 
Fabien.