Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAbYW-0008WV-8N for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Nov 2017 12:58:40 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eAbYV-0002pB-RL for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Nov 2017 12:58:39 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eAbYU-0002k1-AR for pgsql-hackers@postgresql.org; Fri, 03 Nov 2017 12:58:38 +0000 Received: from mail-qk0-x22c.google.com ([2607:f8b0:400d:c09::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1eAbYQ-0004Op-DI for pgsql-hackers@postgresql.org; Fri, 03 Nov 2017 12:58:37 +0000 Received: by mail-qk0-x22c.google.com with SMTP id d67so3052540qkg.5 for ; Fri, 03 Nov 2017 05:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adjust.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jde1OusmLbJE3MGnP0lgYMWXeSbiY3ZukwXYdxPLVYI=; b=OXEVxZtCizDv21RAvxTNqmYav0qcwSTgT2dkmG9RbgcyUOamVFFsLOzT2shT6f2p82 PD5uTl43+0wtrJWyNjj6R7KgwD5ES1qIlNdDx8mU/Ok2L20V8ZeWVHCsMq02YhFSbu/6 w6erZEsaRVOcYY16lKDeytmXTxl87ad9mtACWHWBKTpdCSbp03w3TRFcJ9otMJjy9ck4 VwSNlOM0p9nN6gI1vRemBXhfnKZLbztqebhZ/vv45VF/K+HZ82smHYSyj0ZLwxZliXHj Qb6KflZ4UlBXJdQrz8G0cjcrgCqAFipAWMyp18OL1VIhLSPmTPvpiScuDf8N2msETfI5 BJBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jde1OusmLbJE3MGnP0lgYMWXeSbiY3ZukwXYdxPLVYI=; b=Tw95o5wR1ncsiKKqdGUNAz6fLNrUow+uGEZ0O3pTR4q6P7Z7/NUkmSNun8PQPVojHL XSQMOYXpcuUfJkMErXmbTn6riRN1Drpwcnfbe62Za9nlkDQSPZlXeHiEUiVQepo7NaDt MT/fn8hc8RAPrZUV7zqEQdEBeMSWWSX50a07p/cLY+NQOQYY2XLH89ka5PFwOc7vj19b hILeZ9VnHxrMlyExnawGT8Y7KaLjFWcss96BRYdRKmRTHkDdjqS1xYeLAZmfr9QgA/Ik Hucrtkmm4BFU5aLBoUwdi80p0eLHoLIQ+FSAx5lvUohXPPeinMreET/9DnLmHhgUdhPQ hZZQ== X-Gm-Message-State: AJaThX6+n5/KDoATHtiN6n7q3dF8LXH97m0qzgOM3fNl7ufSyPLtmEEh KW++/WLU3HI0QwyFMApMTKh4Gfuojomyp4oGqPr6Iw== X-Google-Smtp-Source: ABhQp+R+DB9hSkrU4pEOYr74X7mPX6/fIBgLIihB/VIsumDyMW+5me2V9fdsrIf7bx+UzDbpKtEfLEIKKSXkzc5Sfd4= X-Received: by 10.55.207.20 with SMTP id e20mr9804836qkj.1.1509713913144; Fri, 03 Nov 2017 05:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.96.40 with HTTP; Fri, 3 Nov 2017 05:58:02 -0700 (PDT) In-Reply-To: <28927.1509637724@sss.pgh.pa.us> References: <20171102153505.GP4496@localhost> <28927.1509637724@sss.pgh.pa.us> From: Chris Travers Date: Fri, 3 Nov 2017 13:58:02 +0100 Message-ID: Subject: Re: proposal: schema variables To: Tom Lane Cc: Nico Williams , Robert Haas , Pavel Stehule , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="001a1145909c817d4e055d13a91f" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --001a1145909c817d4e055d13a91f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Some thoughts on this. On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane wrote: > Nico Williams 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 Unifie= d > 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=3D'bar'; Perhaps one can have a short form of: SET VAR foo =3D 'bar'; vs SET foo =3D '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 > --=20 Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbr=C3=BCcker Stra=C3=9Fe 37a, 10405 Berlin --001a1145909c817d4e055d13a91f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some thoughts on this.

<= div class=3D"gmail_quote">On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane <tgl@ss= s.pgh.pa.us> wrote:
Nico Williams <nico@c= ryptonector.com> writes:
> With access controls, GUCs could become schema variables, and settings=
> from postgresql.conf could move into the database itself (which I thin= k
> 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 un= ification, you still have some things in the db and some things out.
<= div>
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 s= olution.

=C2=A0One major use case today would be r= estricting how high various users can set something like work_mem or the li= ke.=C2=A0 As it stands, there isn't really a way to control this with a= ny granularity.=C2=A0 So some of the proposals regarding granting access to= a session variable would be very handy in granting access to a GUC variabl= e.

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.=C2=A0 The point of the Grand= Unified
Configuration mechanism was to be unified, after all.
=
+1=C2=A0

I'm on board with having a totally different mechanism for session
variables.=C2=A0 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=3D'bar';

<= div>Perhaps one can have a short form of:

SET VAR = foo =3D 'bar';

vs

SET foo =3D 'bar'; -- GUC

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 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-hacker= s



--
=
Best Regards,
Chris Tra= vers
Database Administrator

Tel:=C2=A0+49 162 9037 210=C2=A0| Skype: einhverfr |=C2=A0www.adjust= .com=C2=A0
Saarbr=C3=BCcker Stra=C3=9Fe 37a, 10405 Berlin
<= div>
--001a1145909c817d4e055d13a91f--