That's a good point.
A command is more straightforward because it targets only one backend.
The user is supposed to know which backend pid is taking a long time to complete based on pg_stat_activity().
This is somehow the same approach as EXPLAIN command.
But the use is limited to psql utility. And this adds one more command.
I see 2 possible choices:
1 - either convert the command into a table.
This is the way it is done on Oracle database with v$session_longops view. Obviously, this requires probing the status of each backend. This inconvenient can be mitigated by using a threeshold of a few seconds before considering a backend progression. v$session_longops only reports long running queries after at least 6 seconds of execution.
This is less efficient that targeting directly a given pid or backend id. But this is far better for SQL.
2 - either convert the command into a function
The advantage of a function is that it can accept parameters. So parameters could be the pid of the backend, the verbosity level, the format (text, json, ....).
This would not reduce the options of the current command. And then a view could be created on top of the function.
May be a mix of both a function with parameters and a view created on the function is the solution.
Regards
Remi
