On Thu, Sep 19, 2013 at 6:19 PM, Andres Freund <and...@2ndquadrant.com> wrote:
> On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
>> On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund <and...@2ndquadrant.com>
>> wrote:
>> > I think that ship has long since sailed. postgresql.conf has allowed
>> > foo.bar style GUCs via custom_variable_classes for a long time, and
>> > these days we don't even require that but allow them generally. Also,
>> > SET, postgres -c, and SELECT set_config() already don't have the
>> > restriction to one dot in the variable name.
>>
>> Well, we should make it consistent, but I'm not sure that settles the
>> question of which direction to go.
>
> I suggested making it consistent in either form elsewhere in this
> thread, Tom wasn't convinced. I think because of backward compatibility
> concerns we hardly can restrict the valid namespace in all forms to the
> most restrictive form (i.e. guc-file.l). Quite some people use GUCs as
> variables.
> Maybe we can forbid the more absurd variants (SET "..."."..." = 3;
> SELECT set_config('...', '1', true)), but restricting it entirely seems
> to cause pain for no reason.
Yeah, I don't think I understand Tom's reasoning. I mean, why
shouldn't there be ONE rule for what can be a GUC?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
