Re: proposal: psql PSQL_TABULAR_PAGER variable

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: psql PSQL_TABULAR_PAGER variable
Дата
Msg-id CAFj8pRAyxBGnFuBrL71jvOF8pD1xO670XCoqsaUCVe4txgFvGg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: psql PSQL_TABULAR_PAGER variable  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


po 22. 4. 2019 v 16:21 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Robert Haas <robertmhaas@gmail.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 :-(.

pspg supports both direction scrolling, so data are in buffer, and can be displayed again.


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.

The programs with some complex output usually doesn't use a pagers - or use pagers only for part of their output.

Initially I would to teach "less" to support tabular data - but the after some initial research I found so I am not able to modify "less".


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.

It can be a way. There are some issues unfixable on pager side - like dynamic column resizing when FETCH_COUNT > 0 and some others.

I can imagine a situation, when psql send just raw data in some easy machine readable format (like CSV), and specialized pager can format these data, and can support some interactive work (hiding columns, columns switch, ..)

Regards

Pavel
 

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: psql PSQL_TABULAR_PAGER variable
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_dump is broken for partition tablespaces