Re: Forgive trailing semicolons inside of config files

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Forgive trailing semicolons inside of config files
Дата
Msg-id CAMsGm5f_nr+V_HBxesN0cAk=7+WEgo6oxp-aCa2d4coetTYOXA@mail.gmail.com
обсуждение исходный текст
Ответ на Forgive trailing semicolons inside of config files  (Greg Sabino Mullane <htamfids@gmail.com>)
Ответы Re: Forgive trailing semicolons inside of config files  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Forgive trailing semicolons inside of config files  (Greg Sabino Mullane <htamfids@gmail.com>)
Список pgsql-hackers
On Tue, 11 Jul 2023 at 10:43, Greg Sabino Mullane <htamfids@gmail.com> wrote:
This has been a long-standing annoyance of mine. Who hasn't done something like this?:

psql> SET random_page_cost = 2.5;
(do some stuff, realize that rpc was too high)

Let's put that inside of postgresql.conf:

#------------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#------------------------------------------------------------------------------

# Add settings for extensions here                                                                                                    
random_page_cost = 2.5;


Boom! Server will not start. Surely, we can be a little more liberal in what we accept? Attached patch allows a single trailing semicolon to be silently discarded. As this parsing happens before the logging collector starts up, the error about the semicolon is often buried somewhere in a separate logfile or journald - so let's just allow postgres to start up since there is no ambiguity about what random_page_cost (or any other GUC) is meant to be set to.

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?

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.

Or maybe there could be a "check configuration" subcommand which checks the configuration. If it's fine, say so and set a flag saying the server is clear to be started/restarted. If not, give useful error messages and don't set the flag. Then make the start/restart commands only do their thing if the "config OK" flag is set. Make sure that editing the configuration clears the flag (or have 2 copies of the configuration, copied over by the "check" subcommand: one for editing, one for running with).

This might properly belong outside of Postgres itself, I don't know. But I think it would be way more useful than a potentially never-ending series of patches to liberalize the config parser.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes
Следующее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Latches vs lwlock contention