Message-ID: <4b96eb7c-1390-4fb8-82b5-da27a62b9a1f@uni-muenster.de>
Date: Fri, 24 Apr 2026 12:41:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: PoC - psql - emphases line with table name in verbose output
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAFj8pRD2MOak45s8=bex3BcncJf2jt9ukx=i9pKmWB1SepZu6g@mail.gmail.com>
 <CAFj8pRDarWO-OsR+u0dWs=Y6aVOc+ebb_PJH8CdUuwmdOmR4tA@mail.gmail.com>
 <c978cb1a-c0e6-42f4-9a65-5f19dbf67682@uni-muenster.de>
 <CAFj8pRBnpqCUWtDZvpBJ+jExVWYPxDuJdfw8HLGt9bmeEBr=eQ@mail.gmail.com>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: 
 <CAFj8pRBnpqCUWtDZvpBJ+jExVWYPxDuJdfw8HLGt9bmeEBr=eQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/4b96eb7c-1390-4fb8-82b5-da27a62b9a1f%40uni-muenster.de>
Precedence: bulk


On 24/04/2026 08:56, Pavel Stehule wrote:
> Please, can you check the functionality (only in english). I am
> interested if this is just helpful and if it makes sense to continue in
> this feature. Unfortunately, there are not too many possibilities about
> possible formats, colors in terminals (that can work mostly everywhere). 


I tested it yesterday with lc_messages = 'en_GB.UTF-8' and it worked
just fine. And I also agree that it is currently hard to spot tables in
the verbose output.


> I don't think it is possible to implement this without  communication
> protocol enhancement. And if we will do this, the next question is if we
> cannot use this for some more complex information about the executed
> command.
> 
> For example - I thought about the possibility of teaching psql to read
> progress stat tables - so can be nice, if the server can send some
> information to client - maybe pgstat_progres_update can send INFO 
> 
> like - "emphasize: nextinfo, pid: xxxx, progress table: pg_stat_vacuum,
> commandtype: vacuum, ....
> 
> Maybe a different approach - instead of a plain text message, we can
> send messages of this type in client side parsable format - if I am not
> wrong, we are able to parse json on client side. json is still readable
> for humans for old clients. On the client side we decide what and how we
> will display. This can be more generic than just for VERBOSE mode of
> ANALYZE, VACUUM or REINDEX.
> 
> some like
> 
> elog(INFO_CLIENT, '{ "cmdtag": "VACUUM", "state":"started",
> "progress_tab": "pg_stat_progress_vacuum", "table_name": "yyy",
> "schema_name":"xxx", ...)
> 
> elog(INFO_CLIENT, '{"cmdatag": "VACUUM", "state":"finished",
> "pages_removed": 0, "pages_ ...


I think it is feasible. The question is now is rather, is it worth the
trouble just to highlight an output?

I also don't see an easy way to implement this feature. It's virtually
impossible to do that without some change in the server side. I took a
look at the code and perhaps NoticeProcessor() at common.c would be
better than pg_log_generic_v() for that, but still the problem of
identifying the INFO messages remains.

One option would be to create a new SQLSTATE and add it to the ereport
calls, e.g. ERRCODE_VERBOSE_PROGRESS_INFO

if (verbose)
{
  if (vacrel->aggressive)
    ereport(INFO,
	errcode(ERRCODE_VERBOSE_PROGRESS_INFO),
	(errmsg("aggressively vacuuming \"%s.%s.%s\"",
	  vacrel->dbname, vacrel->relnamespace,
          vacrel->relname)));
  else
    ereport(INFO,
	errcode(ERRCODE_VERBOSE_PROGRESS_INFO),
	(errmsg("vacuuming \"%s.%s.%s\"",
	  vacrel->dbname, vacrel->relnamespace,
	  vacrel->relname)));
}

Then in NoticeProcessor() check for it and act accordingly:

const char *state = PQresultErrorField(result, PG_DIAG_SQLSTATE);
if (state && strcmp(state, "00001") == 0)
 ... apply color / blank line / bold / whatever

But it also looks like we'd be using SQLSTATES incorrectly. That would
certainly require a bit more research.


> I don't see some simple and nice solution at this moment. Maybe just
> using new line after INFO with details


It's much less invasive with more or less the same effect. However, the
Error Message Style Guide explicitly says "Don't put any specific
assumptions about formatting into the message texts" and "Don't end a
message with a newline"[1]. So I'm afraid it's not an option either :\
Of course, it could also disturb external tools that parse the verbose
output, but that alone wouldn't be a blocker IMHO.

Thanks!

Best, Jim

1 -
https://www.postgresql.org/docs/current/error-style-guide.html#ERROR-STYLE-GUIDE-FORMATTING