Re: Patch: initdb: "'" for QUOTE_PATH (non-windows) - Mailing list pgsql-hackers

From Ryan Murphy
Subject Re: Patch: initdb: "'" for QUOTE_PATH (non-windows)
Date
Msg-id CAHeEsBdhAoq6_Tsv5bKKQr9M6iDPxn4na=1DsoDtXESDkqkxCQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch: initdb: "'" for QUOTE_PATH (non-windows)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch: initdb: "'" for QUOTE_PATH (non-windows)  (Ryan Murphy <ryanfmurphy@gmail.com>)
List pgsql-hackers


On Thu, Aug 18, 2016 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ryan Murphy <ryanfmurphy@gmail.com> writes:
> On Thu, Aug 18, 2016 at 3:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> +        { /* pg_ctl command w path, properly quoted */
>>>> +            PQExpBuffer pg_ctl_path = createPQExpBuffer();
>>>> +            printfPQExpBuffer(pg_ctl_path, "%s%spg_ctl",

>> I think it's worth reducing the scope of variables when that's as
>> simple as putting them inside a block that you have to create anyway,
>> but I'm skeptical about the idea that one would create a block just to
>> reduce the scope of the variables.  I don't think that's our usual
>> practice, and I would expect the compiler to detect where the variable
>> is referenced first and last anyway.

> I enjoy adding the blocks for explicit variable scoping and for quick
> navigation in vim (the % key navigates between matching {}'s).  But I want
> to fit in with the style conventions of the project.

Another point here is that code like this will look quite a bit different
after pgindent gets done with it --- that comment will not stay where
you put it, for example.  Some of our worst formatting messes come from
code wherein somebody adhered to their own favorite layout style without
any thought for how it would play with pgindent.

                        regards, tom lane

Ahh, I didn't know about pgindent, but now I see it in /src/tools.  I can run that on my code before submitting.

I found these links about the style convention and will make sure my patch fits the conventions before submitting it.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Making pg_hba.conf case-insensitive
Next
From: Robert Haas
Date:
Subject: Re: Improving planner's checks for parallel-unsafety