From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] Extend namespace of valid guc names |
Date: | 2013-09-06 14:13:23 |
Message-ID: | 28392.1378476803@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
>>> b) allow variables to start with a digit from the second level onwards.
>> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-09-06 14:19:46 | Re: get rid of SQL_ASCII? |
Previous Message | MauMau | 2013-09-06 13:40:10 | [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII |