public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Chris Travers <chris.travers@adjust.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nico Williams <nico@cryptonector.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: proposal: schema variables
Date: Fri, 3 Nov 2017 13:58:02 +0100
Message-ID: <CAN-RpxCAHPujQPA9cRrqOABEX2g5Y1p3hasGMp=EE8hagw7cjw@mail.gmail.com> (raw)
In-Reply-To: <28927.1509637724@sss.pgh.pa.us>
References: <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
<CA+TgmoaZ0iymUS_ZM6LW2yWjabwQs4K8=4GYR1+u-V7ROPz0nA@mail.gmail.com>
<20171102153505.GP4496@localhost>
<28927.1509637724@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Some thoughts on this.
On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Nico Williams <nico@cryptonector.com> writes:
> > 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).
>
> People re-propose some variant of that every so often, but it never works,
> because it ignores the fact that some of the GUCs' values are needed
> before you can access system catalogs at all, or in places where relying
> on system catalog access would be a bad idea.
>
I think the basic point one should get here is that no matter the
unification, you still have some things in the db and some things out.
I would rather look at how the GUC could be improved on a functional/use
case level before we look at the question of a technical solution.
One major use case today would be restricting how high various users can
set something like work_mem or the like. As it stands, there isn't really
a way to control this with any granularity. So some of the proposals
regarding granting access to a session variable would be very handy in
granting access to a GUC variable.
>
> Sure, we could have two completely different configuration mechanisms
> so that some of the variables could be "inside the database", but that
> doesn't seem like a net improvement to me. The point of the Grand Unified
> Configuration mechanism was to be unified, after all.
>
+1
>
> I'm on board with having a totally different mechanism for session
> variables. The fact that people have been abusing GUC to store
> user-defined variables doesn't make it a good way to do that.
>
What about having a more clunky syntax as:
SET VARIABLE foo='bar';
Perhaps one can have a short form of:
SET VAR foo = 'bar';
vs
SET foo = 'bar'; -- GUC
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
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: pgsql-performance@postgresql.org
Cc: chris.travers@adjust.com, tgl@sss.pgh.pa.us, nico@cryptonector.com, robertmhaas@gmail.com, pavel.stehule@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: proposal: schema variables
In-Reply-To: <CAN-RpxCAHPujQPA9cRrqOABEX2g5Y1p3hasGMp=EE8hagw7cjw@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