2016-12-29 9:36 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > 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.rst
getter/setter functions are implementation in first step. I spoke, so this step is not last. > > > - 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 disagree - some concepts are more robust, other less. Regards Pavel > > I have open a wiki page to help with this discussion: > > https://wiki.postgresql.org/wiki/Variable_Design > > -- > Fabien. >
