Re: [RFC] Extend namespace of valid guc names

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [RFC] Extend namespace of valid guc names
Date: 2013-09-06 14:31:56
Message-ID: 20130906143156.GE600952@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> >> That seems like a seriously bad idea. I note that SET does *not* allow
> >> this;
>
> > Hm. One thing about this is that we currently allow something silly as:
> > SET "1"."1bar""blub" = 3;
>
> > So I'd like to either restrict SET here or allow the same for guc-file.l
> > parsed GUCs. Any opinions?
>
> Well, if you feel an absolute compulsion to make them consistent, I'd
> go with making SET disallow creation of variables with names the file
> parser wouldn't recognize. But why is it such a bad thing if SET can
> do that? The whole reason we allow SET to create new variables at all
> is that the universe of things you can have as session-local values is
> larger than the set of parameters that are allowed in postgresql.conf.
> So I'm missing why we need such a restriction.

Well, it's confusing for users, i.e. me. I've several times now
prototyped stuff that was supposed to be configurable in postgresql.conf
by either passing the options to postgres -c or by doing user level
SETs. Only to then later discover that what I've prototyped doesn't work
because the restrictions in postgresql.conf are way stricter.

Also, ALTER SYSTEM SET is going to need a similar restriction as well,
otherwise the server won't restart although the GUCs pass validation...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-09-06 14:37:16 Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Previous Message Tom Lane 2013-09-06 14:19:46 Re: get rid of SQL_ASCII?