proposal: psql PSQL_TABULAR_PAGER variable

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule
Hi

I wrote a pspg pager https://github.com/okbob/pspg

This pager is designed for tabular data. It can work in fallback mode as classic pager, but it is not designed for this purpose (and I don't plan do it). Can we enhance a set of psql environment variables about PSQL_TABULAR_PAGER variable. This pager will be used, when psql will display tabular data.

Comments, notes?

Regards

Pavel
Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Bruce Momjian
On Thu, Apr 18, 2019 at 07:20:37AM +0200, Pavel Stehule wrote:
> Hi
>
> I wrote a pspg pager https://github.com/okbob/pspg
>
> This pager is designed for tabular data. It can work in fallback mode as
> classic pager, but it is not designed for this purpose (and I don't plan do
> it). Can we enhance a set of psql environment variables about
> PSQL_TABULAR_PAGER variable. This pager will be used, when psql will display
> tabular data.

In testing pspg, it seems to work fine with tabular and \x-non-tabular
data.  Are you asking for a pager option that is only used for non-\x
display?  What do people want the non-pspg pager to do?

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule


čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian <[hidden email]> napsal:
On Thu, Apr 18, 2019 at 07:20:37AM +0200, Pavel Stehule wrote:
> Hi
>
> I wrote a pspg pager https://github.com/okbob/pspg
>
> This pager is designed for tabular data. It can work in fallback mode as
> classic pager, but it is not designed for this purpose (and I don't plan do
> it). Can we enhance a set of psql environment variables about
> PSQL_TABULAR_PAGER variable. This pager will be used, when psql will display
> tabular data.

In testing pspg, it seems to work fine with tabular and \x-non-tabular
data.  Are you asking for a pager option that is only used for non-\x
display?  What do people want the non-pspg pager to do?

My idea is following - pseudocode


if view is a table
{
  if is_defined PSQL_TABULAR_PAGER
  {
    pager = PSQL_TABULAR_PAGER
  }
  else if is_defined PSQL_PAGER
  {
    pager = PSQL_PAGER
  }
  else
  {
    pager = PAGER
  }
}
else /* for \h xxx */
{
  if is_defined PSQL_PAGER
  {
    pager = PSQL_PAGER
  }
  else
  {
    pager = PAGER
  }
}
 
I expect some configuration like

PSQL_TABULAR_PAGER=pspg
PSQL_PAGER="less -S"

Regards

Pavel



--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Bruce Momjian
On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian <[hidden email]> napsal:
>     In testing pspg, it seems to work fine with tabular and \x-non-tabular
>     data.  Are you asking for a pager option that is only used for non-\x
>     display?  What do people want the non-pspg pager to do?
>
> My idea is following - pseudocode
>
> else /* for \h xxx */

Well, normal output and \x looks fine in pspg, and \h doesn't use the
pager unless it is more than one screen.  If I do '\h *' it uses pspg,
but now often do people do that?  Most \h display doesn't use a pager,
so I don't see the point.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule


čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian <[hidden email]> napsal:
On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian <[hidden email]> napsal:
>     In testing pspg, it seems to work fine with tabular and \x-non-tabular
>     data.  Are you asking for a pager option that is only used for non-\x
>     display?  What do people want the non-pspg pager to do?
>
> My idea is following - pseudocode
>
> else /* for \h xxx */

Well, normal output and \x looks fine in pspg, and \h doesn't use the
pager unless it is more than one screen.  If I do '\h *' it uses pspg,
but now often do people do that?  Most \h display doesn't use a pager,
so I don't see the point.

It depends on terminal size. On my terminal pager is mostly every time. \? is same.

pspg can works like classic pager, but it is not optimized for this purpose.





--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Bruce Momjian
On Thu, Apr 18, 2019 at 06:06:40PM +0200, Pavel Stehule wrote:

>
>
> čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian <[hidden email]> napsal:
>
>     On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
>     > čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian <[hidden email]>
>     napsal:
>     >     In testing pspg, it seems to work fine with tabular and \
>     x-non-tabular
>     >     data.  Are you asking for a pager option that is only used for non-\x
>     >     display?  What do people want the non-pspg pager to do?
>     >
>     > My idea is following - pseudocode
>     >
>     > else /* for \h xxx */
>
>     Well, normal output and \x looks fine in pspg, and \h doesn't use the
>     pager unless it is more than one screen.  If I do '\h *' it uses pspg,
>     but now often do people do that?  Most \h display doesn't use a pager,
>     so I don't see the point.
>
>
> It depends on terminal size. On my terminal pager is mostly every time. \? is
> same.
>
> pspg can works like classic pager, but it is not optimized for this purpose.

Uh, the odd thing is that \? and sometimes \h are the only case I can
see where using the classic page has much value.  Are there more cases?
If not, I don't see the value in having a separate configuration
variable for this.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule


čt 18. 4. 2019 v 18:35 odesílatel Bruce Momjian <[hidden email]> napsal:
On Thu, Apr 18, 2019 at 06:06:40PM +0200, Pavel Stehule wrote:
>
>
> čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian <[hidden email]> napsal:
>
>     On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
>     > čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian <[hidden email]>
>     napsal:
>     >     In testing pspg, it seems to work fine with tabular and \
>     x-non-tabular
>     >     data.  Are you asking for a pager option that is only used for non-\x
>     >     display?  What do people want the non-pspg pager to do?
>     >
>     > My idea is following - pseudocode
>     >
>     > else /* for \h xxx */
>
>     Well, normal output and \x looks fine in pspg, and \h doesn't use the
>     pager unless it is more than one screen.  If I do '\h *' it uses pspg,
>     but now often do people do that?  Most \h display doesn't use a pager,
>     so I don't see the point.
>
>
> It depends on terminal size. On my terminal pager is mostly every time. \? is
> same.
>
> pspg can works like classic pager, but it is not optimized for this purpose.

Uh, the odd thing is that \? and sometimes \h are the only case I can
see where using the classic page has much value.  Are there more cases?
If not, I don't see the value in having a separate configuration
variable for this.

I don't know any about other cases. Other results in psql has tabular format.

Pavel


--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Alvaro Herrera-9
On 2019-Apr-18, Pavel Stehule wrote:

> I don't know any about other cases. Other results in psql has tabular
> format.

What about EXPLAIN?

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule


čt 18. 4. 2019 v 21:12 odesílatel Alvaro Herrera <[hidden email]> napsal:
On 2019-Apr-18, Pavel Stehule wrote:

> I don't know any about other cases. Other results in psql has tabular
> format.

What about EXPLAIN?

I forgot it, thank you

Pavel


--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Robert Haas
In reply to this post by Pavel Stehule
On Thu, Apr 18, 2019 at 11:46 AM Pavel Stehule <[hidden email]> wrote:

> My idea is following - pseudocode
>
> if view is a table
> {
>   if is_defined PSQL_TABULAR_PAGER
>   {
>     pager = PSQL_TABULAR_PAGER
>   }
>   else if is_defined PSQL_PAGER
>   {
>     pager = PSQL_PAGER
>   }
>   else
>   {
>     pager = PAGER
>   }
> }
> else /* for \h xxx */
> {
>   if is_defined PSQL_PAGER
>   {
>     pager = PSQL_PAGER
>   }
>   else
>   {
>     pager = PAGER
>   }
>

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Tom Lane-2
Robert Haas <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule
In reply to this post by Robert Haas


po 22. 4. 2019 v 15:46 odesílatel Robert Haas <[hidden email]> napsal:
On Thu, Apr 18, 2019 at 11:46 AM Pavel Stehule <[hidden email]> wrote:
> My idea is following - pseudocode
>
> if view is a table
> {
>   if is_defined PSQL_TABULAR_PAGER
>   {
>     pager = PSQL_TABULAR_PAGER
>   }
>   else if is_defined PSQL_PAGER
>   {
>     pager = PSQL_PAGER
>   }
>   else
>   {
>     pager = PAGER
>   }
> }
> else /* for \h xxx */
> {
>   if is_defined PSQL_PAGER
>   {
>     pager = PSQL_PAGER
>   }
>   else
>   {
>     pager = PAGER
>   }
>

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.

This is possible, and I wrote it. But it is "little bit" strange, start another pager from a pager.

I think so task oriented pagers can enhance custom experience of TUI applications - and there is a big space for enhancement.

Currently pspg have to reparse data and there are some heuristic to detect format. Can be nice, if psql can send some additional info about the data.

Maybe psql can send raw data, and printing formatting can be on parser side.

Pavel

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Reply | Threaded
Open this post in threaded view
|

Re: proposal: psql PSQL_TABULAR_PAGER variable

Pavel Stehule
In reply to this post by Tom Lane-2


po 22. 4. 2019 v 16:21 odesílatel Tom Lane <[hidden email]> napsal:
Robert Haas <[hidden email]> 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