On Wed, Dec 25, 2013 at 2:36 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Tue, Dec 24, 2013 at 1:58 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera >>> <alvhe...@2ndquadrant.com> wrote: >>>> Michael Paquier escribió: >>>>> On Fri, Dec 20, 2013 at 1:05 PM, Sawada Masahiko <sawada.m...@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.1384917...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers