Re: Spacing of options in getopt_long processing

On 2025-Nov-04, Andrew Dunstan wrote:

> 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?

I think not all switch blocks are the same. In getopt_long() switch
blocks, I think the empty lines are mostly useless, because the 'break'
plus the changing indentation for the next line is sufficient visual
cue, and the vertical space _is_ worth more than zero. But if you go to
more complex switches (say xact.c ones) then the empty lines are quite
necessary, especially given pgindent's tendency to add indentation to
comments immediately preceding a case line (but even without that).

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
[…] indem ich in meinem Leben oft an euch gedacht, euch glücklich zu machen. Seyd es!
A menudo he pensado en vosotros, en haceros felices. ¡Sedlo, pues!
Heiligenstädter Testament, L. v. Beethoven, 1802
https://de.wikisource.org/wiki/Heiligenstädter_Testament