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.
- 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 have open a wiki page to help with this discussion:
https://wiki.postgresql.org/wiki/Variable_Design
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
