MIME-Version: 1.0
In-Reply-To: 
 <CA+TgmoaZ0iymUS_ZM6LW2yWjabwQs4K8=4GYR1+u-V7ROPz0nA@mail.gmail.com>
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <CA+TgmoaZ0iymUS_ZM6LW2yWjabwQs4K8=4GYR1+u-V7ROPz0nA@mail.gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Thu, 2 Nov 2017 16:49:20 +0100
Message-ID: 
 <CAFj8pRCwTf6kqk8Z+5x8y6F=-S1gP2JTchKnjf2ixf2AMMpahw@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="001a11441764e686a0055d01f04f"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--001a11441764e686a0055d01f04f
Content-Type: text/plain; charset="UTF-8"

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
>

--001a11441764e686a0055d01f04f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-11-02 13:35 GMT+01:00 Robert Haas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:robertmhaas@gmail.com" target=3D"_blank">robertmhaas@gmail.com</a>&=
gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Thu, Oct =
26, 2017 at 12:51 PM, Pavel Stehule &lt;<a href=3D"mailto:pavel.stehule@gma=
il.com">pavel.stehule@gmail.com</a>&gt; wrote:<br>
&gt; The variables can be modified by SQL command SET (this is taken from<b=
r>
&gt; standard, and it natural)<br>
&gt;<br>
&gt; SET varname =3D expression;<br>
<br>
</span>Overloading SET to handle both variables and GUCs seems likely to<br=
>
create problems, possibly including security problems.=C2=A0 For example,<b=
r>
maybe a security-definer function could leave behind variables to<br>
trick the calling code into failing to set GUCs that it intended to<br>
set.=C2=A0 Or maybe creating a variable at the wrong time will just break<b=
r>
things randomly.<br></blockquote><div><br></div><div>The syntax CREATE OR R=
EPLACE FUNCTION xxx $$ ... $$ SET GUC=3D, ... is always related only to GUC=
. So there should not be any security risk. <br></div><div><br></div><div>I=
t is another reason why GUC and variables should be separated.</div><div><b=
r></div><div>I know so there is risk of possibility of collision. There are=
 two possibilities</div><div><br></div><div>a) use different keyword - but =
it is out of SQL/PSM and out of another databases.</div><div><br></div><div=
>b) detect possible collision and raise error when assignment is ambiguous.=
 I am thinking about similar solution used in plpgsql, where is a possibili=
ty of collision between SQL identifier and plpgsql variable.</div><div><br>=
</div><div>Regards</div><div><br></div><div>Pavel<br></div><div><br></div><=
div><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Robert Haas<br>
EnterpriseDB: <a href=3D"http://www.enterprisedb.com" rel=3D"noreferrer" ta=
rget=3D"_blank">http://www.enterprisedb.com</a><br>
The Enterprise PostgreSQL Company<br>
</font></span></blockquote></div><br></div></div>

--001a11441764e686a0055d01f04f--