Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id CAFj8pRCYhvyy=YeWcmvteLkrB4OAAn62FL9aqg50OjHUj6GQbQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] proposal: session server side variables
List pgsql-hackers


2016-12-29 9:36 GMT+01:00 Fabien COELHO <coelho@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.

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables