Re: Forgive trailing semicolons inside of config files - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Forgive trailing semicolons inside of config files
Date
Msg-id CAKAnmmJBdThcjL_Anm_r_eYswNv95NWMPe+AaTg_pcbCFPn63w@mail.gmail.com
Whole thread Raw
In response to Re: Forgive trailing semicolons inside of config files  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: Forgive trailing semicolons inside of config files
List pgsql-hackers
On Tue, Jul 11, 2023 at 11:04 AM Isaac Morland <isaac.morland@gmail.com> wrote:
Please, no!

There is no end to accepting sloppy syntax. What next, allow "SET random_page_cost = 2.5;" (with or without semicolon) in config files?

Well yes, there is an end. A single, trailing semicolon. Full stop. It's not a slippery slope in which we end up asking the AI parser to interpret our haikus to derive the actual value. The postgresql.conf file is not some finicky YAML/JSON beast - we already support some looseness in quoting or not quoting values, optional whitespace, etc. Think of the trailing semicolon as whitespace, if you like. You can see from the patch that this does not replace EOL/EOF.
 
I'd be more interested in improvements in visibility of errors. For example, maybe if I try to start the server and there is a config file problem, I could somehow get a straightforward error message right in the terminal window complaining about the line of the configuration which is wrong.

That ship has long since sailed. We already send a detailed error message with the line number, but in today's world of "service start", "systemctl start", and higher level of control such as Patroni and Kubernetes, getting things to show in a terminal window isn't happening. We can't work around 2>&1.
  
Or maybe there could be a "check configuration" subcommand which checks the configuration.

There are things inside of Postgres once it has started, but yeah, something akin to visudo would be nice for editing config files.
 
But I think it would be way more useful than a potentially never-ending series of patches to liberalize the config parser.

It's a single semicolon, not a sign of the parser apocalypse. I've no plans for future enhancements, but if they do no harm and make Postgres more user friendly, I will support them.

Cheers,
Greg

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Next
From: Nathan Bossart
Date:
Subject: Re: add non-option reordering to in-tree getopt_long