MIME-Version: 1.0
In-Reply-To: <20171102153505.GP4496@localhost>
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <CA+TgmoaZ0iymUS_ZM6LW2yWjabwQs4K8=4GYR1+u-V7ROPz0nA@mail.gmail.com>
 <20171102153505.GP4496@localhost>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Thu, 2 Nov 2017 16:40:36 +0100
Message-ID: 
 <CAFj8pRCzLyni0JBMvjqNA7ey1c-0EEJKSAJJ8rHmSwxfFP1rBA@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Nico Williams <nico@cryptonector.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="001a1145ac7aa7e94a055d01d154"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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

2017-11-02 16:35 GMT+01:00 Nico Williams <nico@cryptonector.com>:

> On Thu, Nov 02, 2017 at 06:05:54PM +0530, Robert Haas wrote:
> > 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.
>
> That's already true of GUCs, since there are no access controls on
> set_config()/current_setting().
>
> Presumably "schema variables" would really just be GUC-like and not at
> all like lexically scoped variables.  And also subject to access
> controls, thus an overall improvement on set_config()/current_setting().
>
> With access controls, GUCs could become schema variables, and settings
> from postgresql.conf could move into the database itself (which I think
> would be nice).
>

I am sorry, but I don't plan it. the behave of GUC is too different than
behave of variables. But I am planning so system GUC can be "moved" to
pg_catalog to be possibility to specify any object exactly.

Regards

Pavel

>
> Nico
> --
>

--001a1145ac7aa7e94a055d01d154
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 16:35 GMT+01:00 Nico Williams <span dir=3D"ltr">&lt;<a href=
=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector.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, N=
ov 02, 2017 at 06:05:54PM +0530, Robert Haas wrote:<br>
&gt; On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule &lt;<a href=3D"mailto:=
pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>&gt; wrote:<br>
&gt; &gt; The variables can be modified by SQL command SET (this is taken f=
rom<br>
&gt; &gt; standard, and it natural)<br>
&gt; &gt;<br>
&gt; &gt; SET varname =3D expression;<br>
&gt;<br>
&gt; Overloading SET to handle both variables and GUCs seems likely to<br>
&gt; create problems, possibly including security problems.=C2=A0 For examp=
le,<br>
&gt; maybe a security-definer function could leave behind variables to<br>
&gt; trick the calling code into failing to set GUCs that it intended to<br=
>
&gt; set.=C2=A0 Or maybe creating a variable at the wrong time will just br=
eak<br>
&gt; things randomly.<br>
<br>
</span>That&#39;s already true of GUCs, since there are no access controls =
on<br>
set_config()/current_setting()<wbr>.<br>
<br>
Presumably &quot;schema variables&quot; would really just be GUC-like and n=
ot at<br>
all like lexically scoped variables.=C2=A0 And also subject to access<br>
controls, thus an overall improvement on set_config()/current_setting()<wbr=
>.<br>
<br>
With access controls, GUCs could become schema variables, and settings<br>
from postgresql.conf could move into the database itself (which I think<br>
would be nice).<br></blockquote><div><br></div><div>I am sorry, but I don&#=
39;t plan it. the behave of GUC is too different than behave of variables. =
But I am planning so system GUC can be &quot;moved&quot; to pg_catalog to b=
e possibility to specify any object exactly.</div><div><br></div><div>Regar=
ds</div><div><br></div><div>Pavel<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>
Nico<br>
--<br>
</font></span></blockquote></div><br></div></div>

--001a1145ac7aa7e94a055d01d154--