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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
