From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Forgive trailing semicolons inside of config files |
Date: | 2023-07-11 15:04:44 |
Message-ID: | CAMsGm5f_nr+V_HBxesN0cAk=7+WEgo6oxp-aCa2d4coetTYOXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 11 Jul 2023 at 10:43, Greg Sabino Mullane <htamfids(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2023-07-11 15:11:31 | Re: Latches vs lwlock contention |
Previous Message | Ashutosh Bapat | 2023-07-11 15:00:41 | Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes |