Re: Add version and data directory to initdb output - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Add version and data directory to initdb output |
| Date | |
| Msg-id | CAKFQuwbNpm+xgr1ywzN8OxjWGH-1CLzbkFwtCr8JHDYwxEuaZA@mail.gmail.com Whole thread Raw |
| In response to | Re: Add version and data directory to initdb output (Daniel Gustafsson <daniel@yesql.se>) |
| Responses |
Re: Add version and data directory to initdb output
(Daniel Gustafsson <daniel@yesql.se>)
Re: Add version and data directory to initdb output (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
| List | pgsql-hackers |
On Tue, Apr 19, 2022 at 2:28 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 16 Apr 2022, at 01:50, David G. Johnston <david.g.johnston@gmail.com> wrote:
> initdb is already pretty chatty, and the version of the cluster being installed seems useful to include as well.
That seems quite reasonable.
> The data directory is probably less so - though I am thinking that the absolute path would be useful to report, especially when a relative path is specified (I didn't figure that part out yet, figured I'd get the idea approved before working out how to make it happen).
I'm less convinced that it will be worth the additional code to make it
portable across *nix/Windows etc.
ok
> Moving "Success" to that "summary output" line and leaving the optional shell command line just be the shell command made sense to me.
Looking at the output, couldn't it alternatively be printed grouped with the
other info on the cluster, ie the final three rows in the example below:
./bin/initdb -D data
The files belonging to this database system will be owned by user "<username>".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
How about 'The database cluster will be initialized with version "14.2".' added
there, which then can keep the "Success" line in place in case existing scripts
are triggering on that line?
The motivating situation had me placing it as close to the last line as possible so my 8 line or so tmux panel would show it to me without scrolling. The version is all I cared about, but when writing the patch the path seemed to be at least worth considering.
As for "Success", I'm confused about the --no-instructions choice to change it the way it did, but given that precedent I only felt it important to leave the word Success as the leading word on a line. Scripts should be triggering on the exit code anyway and presently --no-instructions removes the Success acknowledgement completely anyway.
David J.
pgsql-hackers by date: