On Thu, Sep 19, 2013 at 2:48 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-09-18 11:02:50 +0200, Andres Freund wrote:
>> On 2013-09-18 11:55:24 +0530, Amit Kapila 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.
>> >
>> > It's even explained in document that a two-part name is allowed for
>> > Customized Options at link:
>> > http://www.postgresql.org/docs/devel/static/runtime-config-custom.html
>>
>> Oh I somehow missed that. I'll need to patch that as well.
>
> Updated patch attached.
old part of line
- PostgreSQL will accept a setting for any two-part parameter name.
new part of line
+ PostgreSQL will accept a setting for any parameter name containing
at least one dot.
If I read new part of line just in context of custom options, it makes
sense, but when I compare with old line I think below lines or variant
of them might make more sense as this line is not restricted to just
custom options:
a. PostgreSQL will accept a setting for any parameter name containing
two or more part parameter names.
b. PostgreSQL will accept a setting for any parameter name containing
one or more dots in parts of parameter names.
It's just how user interpret any line, so may be your line is more
meaningful to some users. If you don't think there is any need to
change then keep as it is and let committer decide about it. I don't
have any big problem with the current wording.
I think Robert is still not fully convinced about this patch, but from
my side review of patch with the current scope is complete, so I will
mark it as Ready For Committer if nobody has objections for the same.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
