| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com> |
| Subject: | Spacing of options in getopt_long processing |
| Date: | 2025-11-04 19:32:41 |
| Message-ID: | c4ad4e2f-44de-49e7-8e1b-654a8a2658ff@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2025-11-04 19:51:47 | Re: Have the planner convert COUNT(1) / COUNT(not_null_col) to COUNT(*) |
| Previous Message | Tomas Vondra | 2025-11-04 19:27:52 | Re: PG18 GIN parallel index build crash - invalid memory alloc request size |