psql format output

Hi

st 15. 12. 2021 v 21:16 odesílatel Florian Koch <
florian.murat.koch@gmail.com> napsal:

Hello,

I realized that the output of "\df+ func_name" has a formatting problem
when a
lot of arguments are used. The field 'Arguments data types' gets very long
and
destroys the whole formatting in the console. The field 'Source code' is
most of
the time multi-line and I thought that the output for the field 'Arguments
data
types' could also be multiline with one line for each argument.

try to use pager

https://github.com/okbob/pspg

Regards

Pavel

On 15.12.21 20:58, Florian Koch wrote:

I realized that the output of "\df+ func_name" has a formatting problem
when a
lot of arguments are used. The field 'Arguments data types' gets very
long and
destroys the whole formatting in the console. The field 'Source code' is
most of
the time multi-line and I thought that the output for the field
'Arguments data
types' could also be multiline with one line for each argument.

That's a reasonable idea. I wonder if it would work in general. If
someone had a C function (so no source code) with three arguments, they
might be annoyed if it now displayed as three lines by default.

On Fri, Dec 17, 2021 at 5:08 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:

That's a reasonable idea. I wonder if it would work in general. If
someone had a C function (so no source code) with three arguments, they
might be annoyed if it now displayed as three lines by default.

The problem I see is that each of those three lines would probably wrap.

For example, consider:

rhaas=# \df+ pg_copy_logical_replication_slot

In an 80-column window, the first non-header line of output looks like this:

pg_catalog | pg_copy_logical_replication_slot | record | src_slot_nam

Since we don't even fit the whole parameter name and data type in
there, never mind the rest of the columns, the proposed solution can't
help here. Each of the three output lines are over 300 characters.

When I full-screen my terminal window, it is 254 characters wide. So
if I were working full screen, then this proposal would cause that
output not to wrap when it otherwise would have done so. But if I were
working with a normal size window or even somewhat wider than normal,
it would just give me multiple wrapped lines.

It's hard to make any general judgment about how wide people's
terminal windows are likely to be, but it is my opinion that the root
of the problem is that \df+ just wants to display a whole lot of stuff
- and as hackers add more function properties in the future, they're
likely to get added in here as well. This output format doesn't scale
nicely for that kind of thing, but it's unclear to me what would be
any better.

--
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

It's hard to make any general judgment about how wide people's
terminal windows are likely to be, but it is my opinion that the root
of the problem is that \df+ just wants to display a whole lot of stuff
- and as hackers add more function properties in the future, they're
likely to get added in here as well. This output format doesn't scale
nicely for that kind of thing, but it's unclear to me what would be
any better.

I think the complaint is that even with \x mode, which fixes most
complaints of this sort, the arguments are still too wide:

-[ RECORD 1 ]-------+-----------------------------------------------------------------------------------------------------------
Schema | pg_catalog
Name | pg_copy_logical_replication_slot
Result data type | record
Argument data types | src_slot_name name, dst_slot_name name, OUT slot_name name, OUT lsn pg_lsn
Type | func
Volatility | volatile
Parallel | unsafe
Owner | postgres
Security | invoker
Access privileges |
Language | internal
Source code | pg_copy_logical_replication_slot_c
Description | copy a logical replication slot

The OP wants to fix that by inserting newlines in the "Argument data
types" column, which'd help, but it seems to me to be mostly a kluge.
That's prejudging a lot about how the output will be displayed.
A more SQL-ish way to do things would be to turn the argument items
into a set of rows. I don't quite see how to make that work here,
but maybe I'm just undercaffeinated as yet.

regards, tom lane

On 2021-Dec-20, Tom Lane wrote:

-[ RECORD 1 ]-------+-----------------------------------------------------------------------------------------------------------
Schema | pg_catalog
Name | pg_copy_logical_replication_slot
Result data type | record
Argument data types | src_slot_name name, dst_slot_name name, OUT slot_name name, OUT lsn pg_lsn

The OP wants to fix that by inserting newlines in the "Argument data
types" column, which'd help, but it seems to me to be mostly a kluge.
That's prejudging a lot about how the output will be displayed.
A more SQL-ish way to do things would be to turn the argument items
into a set of rows. I don't quite see how to make that work here,
but maybe I'm just undercaffeinated as yet.

Maybe one way to improve on this is to have the server inject optional
line break markers (perhaps U+FEFF) that the client chooses whether or
not to convert into a physical line break, based on line length. So in
\df we would use a query that emits such a marker after every comma and
then psql measures line width and crams as many items in each line as
will fit. In the above example you would still have a single line for
arguments, because your terminal seems wide enough, but if you use a
smaller terminal then it'd be broken across several.

psql controls what happens because it owns the \df query anyway. It
could be something simple like

pg_catalog.add_psql_linebreaks(pg_catalog.pg_get_function_arguments(p.oid))

if we don't want to intrude into pg_get_function_arguments itself.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Always assume the user will do much worse than the stupidest thing
you can imagine." (Julien PUYDT)