Re: proposal: session server side variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: session server side variables
Date: 2016-12-30 14:34:12
Message-ID: alpine.DEB.2.20.1612301511050.32017@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello again,

>> So any dynamic created object and related operations are not checkable by
>>> plpgsql_check (or any tool).
>>
>> NO. Your first sentence does not imply this very general statement.
>
> If you have not unique definition, you cannot to it. There is not
> possibility different between typo and decision. We are talking about
> static analyze - so code should not be executed - and you don't know
> what function will be started first.

Yes, I assure you that I really know how static analysis works... All the
properties I described below may be proved without executing the code,
that was my point...

>> Some things that I think can be statically proved within a session, that
>> would cover some security concerns:
>>
>> (1) For statically named private dynamic variables declared/used at
>> different points it can be checked without relying on the function order
>> that all declarations are consistent, i.e. the same type, same default
>> value if any.
>
> what is "static" private dynamic variable ? You are using new terminology.

They are my session variable, I just spelled out some properties to be
precise about what I am stating, otherwise it is a mess. The name of the
variable is "static" (statically-named), i.e. it is known directly in the
code. However the variable creation and value are "dynamic".

> Static variables like Clang static variables are not usable - you would to
> share content between different functions.

Sure. I mean static as in "static analysis", i.e. by looking at the code
without executing it, as you put it.

>> (2) (3) (4) [...]
> You are speaking about runtime check.

Not really, I was speaking about properties statically provable, which I
understood was your concern. Now the properties proved may imply a runtime
assumption, for instance that the code has executed without error up to
some point in the program, which is basically impossible to prove
statically.

> BEGIN
> RAISE NOTICE '%', @var;
> END;
>
> Without "execution", you cannot to say if usage of @var is correct or not

It depends about your definition of "correct".

For this very instance it would not matter: if the variable was not
created beforehand, then an error is raised because it does not exist, if
it was created before hand, then an error is raised because that is what
the code is doing... So an error is always raised if the variable is not
right.

> ok, we can use a DECLARE var
>
> DECLARE @var EXTERNAL

I do not know what you mean by 'EXTERNAL'.

> BEGIN
> RAISE NOTICE '%', @var;
> END;
>
> ok, I can do static check - but

> 1. anytime I have to repeat DECLARE statement

Yes, twice in the complete use case: one for the function which checks the
credentials, one for the getter function.

> 2. there is not possible to find typo in DECLARE statement

It is possible to find "some" typos, depending on the code: you can check
that a variable is both assigned and used somewhere, otherwise it is very
probably a typo. Perl does that *statically*, before executing a script.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-12-30 14:57:25 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Previous Message Pavel Stehule 2016-12-30 14:32:41 Re: proposal: session server side variables