Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id CAFj8pRCW9gx85xe5-QV2aVKL-vMgVzmuCktxa+E2is4RxC9rsQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers


2016-12-30 18:39 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:

DECLARE @var EXTERNAL

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

it means "used as shared in session"

Shared by whom? There is no such thing in the proposal I have made on the wiki or in mails. In the proposal variables are private to the role which creates them.

shared by functions in session. 
 


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.

"Before execution" .. I am speaking "without execution".

Before execution is also without execution. You can run "perl -c" to get the warning.

theoretically, if you check all possible functions, you can find some
issues - but you have to check all function on server.

Yes, sure. It seems to be the same with your proposal: if a hidden function drops and recreates a session variable with a different type, or changes its permission, then some static checks are void as well, that is life. Also, a SQL function may access and modify the variables 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.
 
Basically, there may be issues even if static analysis tools says that all is well.

Elsewhere you cannot to find typo in DECLARE statement.

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. 
 

By the way, are you planing to contribute to the wiki?

        https://wiki.postgresql.org/wiki/Variable_Design

I wrote my notes there.


 


--
Fabien.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey