Re: [HACKERS] proposal: schema variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] proposal: schema variables |
| Дата | |
| Msg-id | CAFj8pRCwTf6kqk8Z+5x8y6F=-S1gP2JTchKnjf2ixf2AMMpahw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] proposal: schema variables (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
2017-11-02 13:35 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> The variables can be modified by SQL command SET (this is taken from
> standard, and it natural)
>
> SET varname = expression;
Overloading SET to handle both variables and GUCs seems likely to
create problems, possibly including security problems. For example,
maybe a security-definer function could leave behind variables to
trick the calling code into failing to set GUCs that it intended to
set. Or maybe creating a variable at the wrong time will just break
things randomly.
The syntax CREATE OR REPLACE FUNCTION xxx $$ ... $$ SET GUC=, ... is always related only to GUC. So there should not be any security risk.
It is another reason why GUC and variables should be separated.
I know so there is risk of possibility of collision. There are two possibilities
a) use different keyword - but it is out of SQL/PSM and out of another databases.
b) detect possible collision and raise error when assignment is ambiguous. I am thinking about similar solution used in plpgsql, where is a possibility of collision between SQL identifier and plpgsql variable.
Regards
Pavel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: