Re: proposal: psql PSQL_TABULAR_PAGER variable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: psql PSQL_TABULAR_PAGER variable
Date: 2019-04-22 14:21:39
Message-ID: 4550.1555942899@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Seems like pspg could just hand off to the regular pager if it
> discovers that the input is not in a format it finds suitable.

It might be slightly tricky to do that after having already consumed
some of the input :-(.

Still, I've got to say that I find this proposal pretty horrid.
I already thought that PSQL_PAGER was a dubious idea: what other
program do you know anywhere that isn't satisfied with PAGER?
Inventing still more variables of the same ilk is making it even
messier, and more obviously poorly designed, and more obviously
likely to end up with forty-nine different variables for slightly
different purposes.

I think that the general problem here is "we need psql to be able to
give some context info to pspg", and the obvious way to handle that
is to make a provision for arguments on pspg's command line. That
is, instead of just calling "pspg", call "pspg table" or "pspg help"
etc etc, with the understanding that the set of context words could
be extended over time. We could shoehorn this into what we already
have by saying that PSQL_PAGER is interpreted as a format, and if
it contains say "%c" then replace that with a context word (and
again, there's room for more format codes over time). Probably
best *not* to apply such an interpretation to PAGER, though.

Whether the whole problem is really worth this much infrastructure
is a fair question. But if we're going to do something, I'd rather
go down a path like this than inventing a new environment variable
every month.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2019-04-22 14:25:27 Re: proposal: psql PSQL_TABULAR_PAGER variable
Previous Message Robert Haas 2019-04-22 13:46:36 Re: proposal: psql PSQL_TABULAR_PAGER variable