Spacing of options in getopt_long processing - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Spacing of options in getopt_long processing
Date
Msg-id c4ad4e2f-44de-49e7-8e1b-654a8a2658ff@dunslane.net
Whole thread Raw
List pgsql-hackers
Over at [1] Vaibhav complained that the patch was deleting a line 
following one of the case branches for handling command line options in 
pg_restore.c, and said this was not pertinent to the patch. That's 
reasonable, but it made me look into $subject a bit. pg_restore.c has a 
mixture, with some options being followed by blank lines and some not. 
pg_dumpall.c and pg_dump.c have a blank line after each option, while 
psql's startup.c has none. It would be nice to clean this up and have a 
consistent style. But what style? Personally I think having a blank line 
after each option looks cleaner, and we're not nearly so concerned with 
preserving vertical space as we might once have been. I haven't surveyed 
other utilities in our suite. Is this worth even pursuing? Do we care 
about making each file consistent, or making all the code consistent?


cheers


andrew


[1] 
https://postgr.es/m/CA+vB=AE4SSSqRdPFWxe0zbq1n5ePo8iVHoXQGsu0Xr2srh_yDA@mail.gmail.com

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PG18 GIN parallel index build crash - invalid memory alloc request size
Next
From: "Matheus Alcantara"
Date:
Subject: Re: Have the planner convert COUNT(1) / COUNT(not_null_col) to COUNT(*)