On Wed, Dec 25, 2013 at 2:36 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Dec 24, 2013 at 1:58 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
>>> <alvherre@2ndquadrant.com> wrote:
>>>> Michael Paquier escribió:
>>>>> On Fri, Dec 20, 2013 at 1:05 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>>>>
>>>>> > Sorry the patch which I attached has wrong indent on pg_controldata.
>>>>> > I have modified it and attached the new version patch.
>>>>> Now that you send this patch, I am just recalling some recent email
>>>>> from Tom arguing about avoiding to mix lower and upper-case characters
>>>>> for a GUC parameter name:
>>>>> http://www.postgresql.org/message-id/30569.1384917859@sss.pgh.pa.us
>>>>>
>>>>> To fullfill this requirement, could you replace walLogHints by
>>>>> wal_log_hints in your patch? Thoughts from others?
>>>>
>>>> The issue is with the user-visible variables, not with internal
>>>> variables implementing them. I think the patch is sane. (Other than
>>>> the fact that it was posted as a patch-on-patch instead of
>>>> patch-on-master).
>>>
>>> But spelling it the same way everywhere really improves greppability.
>> Yep, finding all the code paths with a single keyword is usually a
>> good thing. Attached is a purely-aesthetical patch that updates the
>> internal variable name to wal_log_hints.
>
> There are many GUC parameters other than wal_log_hints, that their
> names are not the same as the names of their variables. We should
> update also them?
IMO, this looks hard to accept as some existing extensions would break
(even if fix would be trivial) and it would make back-patching more
difficult. wal_log_hints is a new parameter though...
Regards,
--
Michael