2016-12-28 16:42 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > 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. >
It cannot be - the static analyze is limited to function scope - in static analyze you don't know a order of calls. > > 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... > ... > This is not too friendly - you have to repeat DECLARE in every function. What is somebody somewhere write @fooo or use DECLARE @foo integer instead. There is big space for errors. Regards Pavel > > -- > Fabien. >