public inbox for [email protected]  

help / color / mirror / Atom feed

From: Robert Haas <[email protected]>
To: Nico Williams <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: proposal: schema variables
Date: Thu, 2 Nov 2017 22:51:54 +0530
Message-ID: <CA+TgmoYXZMFp9KuVbkOYeTcSb1wqJifFKSnaamBbzfs3sRvi1Q@mail.gmail.com> (raw)
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>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

On Thu, Nov 2, 2017 at 9:05 PM, Nico Williams <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: proposal: schema variables
  In-Reply-To: <CA+TgmoYXZMFp9KuVbkOYeTcSb1wqJifFKSnaamBbzfs3sRvi1Q@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox