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

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:
  -- I know that there is private a boolean variable "@foo" of unknown
  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:



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to