Re: [RFC] Extend namespace of valid guc names

On Fri, Sep 20, 2013 at 9:48 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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.

I had marked this patch as Ready For Committer, as I think in it's
current scope definition it's ready for next level of review.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com