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: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 2 Nov 2017 22:51:54 +0530
Message-ID: 
 <CA+TgmoYXZMFp9KuVbkOYeTcSb1wqJifFKSnaamBbzfs3sRvi1Q@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Nico Williams <nico@cryptonector.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Thu, Nov 2, 2017 at 9:05 PM, Nico Williams <nico@cryptonector.com> wrote:
>> 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().

No, it isn't.  Right now, SET always refers to a GUC, never a
variable, so there's no possibility of getting confused about whether
it's intending to change a GUC or an eponymous variable.  Once you
make SET able to change either one of two different kinds of objects,
then that possibility does exist.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers