Re: Forgive trailing semicolons inside of config files

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: Forgive trailing semicolons inside of config files
Дата
Msg-id CAKAnmmJBdThcjL_Anm_r_eYswNv95NWMPe+AaTg_pcbCFPn63w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Forgive trailing semicolons inside of config files  (Isaac Morland <isaac.morland@gmail.com>)
Ответы Re: Forgive trailing semicolons inside of config files
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: add non-option reordering to in-tree getopt_long