CheckMyDatabase some error messages in two lines.
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t49758psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 10:46 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t49758_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t49758_1 && git checkout t49758_1Patchset v1 (message #1) is on t49758_1
hi.
https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-FORMATTING
"Don't end a message with a newline."
accidentally, I found some error messages in the function
CheckMyDatabase spread into two lines.
so i try to consolidate them into one line.
On Mon, Jun 10, 2024 at 08:00:00AM +0800, jian he wrote:
https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-FORMATTING
"Don't end a message with a newline."accidentally, I found some error messages in the function
CheckMyDatabase spread into two lines.
so i try to consolidate them into one line.
- errdetail("The database was initialized with LC_COLLATE \"%s\", " - " which is not recognized by setlocale().", collate), + errdetail("The database was initialized with LC_COLLATE \"%s\", which is not recognized by setlocale().", collate),
Both approaches produce the same message. With the existing code, the two
string literals will be concatenated without newlines. It is probably
split into two lines to avoid a long line in the source code.
--
nathan
Nathan Bossart <nathandbossart@gmail.com> writes:
On Mon, Jun 10, 2024 at 08:00:00AM +0800, jian he wrote:
- errdetail("The database was initialized with LC_COLLATE \"%s\", " - " which is not recognized by setlocale().", collate), + errdetail("The database was initialized with LC_COLLATE \"%s\", which is not recognized by setlocale().", collate),
Both approaches produce the same message. With the existing code, the two
string literals will be concatenated without newlines. It is probably
split into two lines to avoid a long line in the source code.
No doubt. People have done it both ways in the past, but I think
currently there's a weak consensus in favor of using one line for
such messages even when it runs past 80 columns, mainly because
that makes it easier to grep the source code for a message text.
But: I don't see too much value in changing this particular instance,
because the line break is in a place where it would not likely cause
you to miss finding the line. You might grep for the first part of
the string or the second part, but probably not for ", which is not".
If the line break were in the middle of a phrase, there'd be more
argument for collapsing it out.
regards, tom lane
On Sun, Jun 09, 2024 at 10:12:53PM -0400, Tom Lane wrote:
No doubt. People have done it both ways in the past, but I think
currently there's a weak consensus in favor of using one line for
such messages even when it runs past 80 columns, mainly because
that makes it easier to grep the source code for a message text.
I recall the same consensus here. Greppability matters across the
board.
But: I don't see too much value in changing this particular instance,
because the line break is in a place where it would not likely cause
you to miss finding the line. You might grep for the first part of
the string or the second part, but probably not for ", which is not".
If the line break were in the middle of a phrase, there'd be more
argument for collapsing it out.
Not sure these ones are worth it, either, so I'd let them be.
--
Michael