Re: psql format output

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Florian Koch <florian(dot)murat(dot)koch(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql format output
Date: 2021-12-20 15:36:15
Message-ID: 202112201536.qrw7pnwwjnya@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2021-12-20 15:37:35 Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.
Previous Message Tom Lane 2021-12-20 15:20:12 Re: psql format output