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.