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

From Fabien COELHO
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id alpine.DEB.2.20.1612311737250.7802@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] proposal: session server side variables
List pgsql-hackers
>> unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is
>> no miracle.
>
> No - metadata, in my design, are persistent - like tables - so you don't
> calculate so any functions can drop a variables. The deployment of secure
> variables is same like table deployment. No dynamic there.

You are missing my point: Static analysis is about proving properties. If 
you need metadata to be persistent, then you should check that it is the 
case, i.e. the static analysis must check that there is no metadata 
changes anywhere. For instance, an analysis tool should reject a function 
which contains:
   GRANT UPDATE ON VARIABLE super_secret_variable TO PUBLIC;

Or does:
   DROP VARIABLE super_secret;   CREATE VARIABLE super_secret ...;

If a static analysis tool is specific to one language, then it can only 
checks that all is well in functions in those languages, but as there may 
be functions written in other languages as well then the check is somehow 
partial. This is not a bad thing, it just illustrate that you cannot check 
everything. That is quality ensurance.

>> [...] Indeed, probably there exists some class of typos that may not be 
>> found by some static analysis implementations on PL/pgSQL functions 
>> which uses basic session variables.
>
> yes, and I would not to append any new case that cannot be covered by 
> plpgsql check. Dynamic SQL and our temporal tables are enough issues 
> already.

I'm not sure that I understand these sentences.

> I wrote my notes there.

Great! I restructured a little bit and tried to improve the English. I 
also added questions when some statement that I think are too optimistic, 
or are unclear to me.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Add doc advice about systemd RemoveIPC
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] cast result of copyNode()