Thread: Re: [GENERAL] Select works only when connected from login postgres
Joseph Brenner <doomvox@gmail.com> writes:
> Well, my take would be that if you've taken the trouble to set an
> empty string as the PAGER that means something, and it probably means
> you don't want any pager to be used.
Yeah, on reflection that argument seems pretty persuasive. So I propose
the attached patch.
BTW, I realized while testing this that there's still one gap in our
understanding of what went wrong for you: cases like "SELECT 'hello'"
should not have tried to use the pager, because that would've produced
less than a screenful of data. But that's irrelevant here, because it
can easily be shown that psql doesn't behave nicely if PAGER is set to
empty when it does try to use the pager.
regards, tom lane
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 261652a..9915731 100644
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*************** $endif
*** 3801,3808 ****
If the query results do not fit on the screen, they are piped
through this command. Typical values are
<literal>more</literal> or <literal>less</literal>. The default
! is platform-dependent. The use of the pager can be disabled by
! using the <command>\pset</command> command.
</para>
</listitem>
</varlistentry>
--- 3801,3809 ----
If the query results do not fit on the screen, they are piped
through this command. Typical values are
<literal>more</literal> or <literal>less</literal>. The default
! is platform-dependent. Use of the pager can be disabled by setting
! <envar>PAGER</envar> to empty, or by using pager-related options of
! the <command>\pset</command> command.
</para>
</listitem>
</varlistentry>
diff --git a/src/fe_utils/print.c b/src/fe_utils/print.c
index 1ec74f1..5c5d285 100644
*** a/src/fe_utils/print.c
--- b/src/fe_utils/print.c
*************** PageOutput(int lines, const printTableOp
*** 2874,2879 ****
--- 2874,2885 ----
pagerprog = getenv("PAGER");
if (!pagerprog)
pagerprog = DEFAULT_PAGER;
+ else
+ {
+ /* if PAGER is empty or all-white-space, don't use pager */
+ if (strspn(pagerprog, " \t\r\n") == strlen(pagerprog))
+ return stdout;
+ }
disable_sigpipe_trap();
pagerpipe = popen(pagerprog, "w");
if (pagerpipe)
diff --git a/src/interfaces/libpq/fe-print.c b/src/interfaces/libpq/fe-print.c
index c33dc42..e596a51 100644
*** a/src/interfaces/libpq/fe-print.c
--- b/src/interfaces/libpq/fe-print.c
*************** PQprint(FILE *fout, const PGresult *res,
*** 166,173 ****
screen_size.ws_col = 80;
#endif
pagerenv = getenv("PAGER");
if (pagerenv != NULL &&
! pagerenv[0] != '\0' &&
!po->html3 &&
((po->expanded &&
nTups * (nFields + 1) >= screen_size.ws_row) ||
--- 166,174 ----
screen_size.ws_col = 80;
#endif
pagerenv = getenv("PAGER");
+ /* if PAGER is unset, empty or all-white-space, don't use pager */
if (pagerenv != NULL &&
! strspn(pagerenv, " \t\r\n") != strlen(pagerenv) &&
!po->html3 &&
((po->expanded &&
nTups * (nFields + 1) >= screen_size.ws_row) ||
Tom Lane wrote:
> BTW, I realized while testing this that there's still one gap in our
> understanding of what went wrong for you: cases like "SELECT 'hello'"
> should not have tried to use the pager, because that would've produced
> less than a screenful of data
At some point emacs was mentioned as the terminal:
>> And I guess I did that intentionally, my .bashrc has
>>
>> # I use emacs shells, I got a "pager" already:
>> export PAGER=''
The M-x shell mode of emacs has a so-called "dumb" terminal
emulation (that's the value of $TERM) where the notion of a "page"
doesn't quite apply.
For instance, when using emacs 24.3 with my default pager on an
Ubuntu desktop, this is what I get:
test=> select 1;
WARNING: terminal is not fully functional
- (press RETURN)
?column?
----------
1
(1 row)
I suspect that psql is unable to determine the screen size
of the "dumb" terminal, and that it's the fault of the terminal
rather than psql.
The warning is displayed by "less" AFAICS.
There are other psql features like tab-completion that don't work
in this mode because emacs interpret keystrokes first for
itself, in effect mixing emacs functionalities with these of the
application run in the terminal. It's awesome sometimes
and irritating at other times depending on what you expect :)
OTOH it has also a M-x term command/mode that provides a
more sophisticated screen emulation into which paging seems
to work exactly like in a normal terminal and the emacs key bindings
are turned off.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
Yes, I have a tendency to use emacs sub-shells (and occasionally M-x sql-postgres)-- I thought I'd reproduced the behavior in an xterm, but I was just trying again and I don't see it. It does seem that the dumbness of my dumb terminal is a factor. If I understand the way this works, it could be an even more baffling behavior if I were using an xterm: with a blank PAGER your output would disappear only if the select exceeded a certain number of lines... On Wed, Dec 7, 2016 at 2:31 AM, Daniel Verite <daniel@manitou-mail.org> wrote: > Tom Lane wrote: > >> BTW, I realized while testing this that there's still one gap in our >> understanding of what went wrong for you: cases like "SELECT 'hello'" >> should not have tried to use the pager, because that would've produced >> less than a screenful of data > > At some point emacs was mentioned as the terminal: > >>> And I guess I did that intentionally, my .bashrc has >>> >>> # I use emacs shells, I got a "pager" already: >>> export PAGER='' > > The M-x shell mode of emacs has a so-called "dumb" terminal > emulation (that's the value of $TERM) where the notion of a "page" > doesn't quite apply. > > For instance, when using emacs 24.3 with my default pager on an > Ubuntu desktop, this is what I get: > > test=> select 1; > WARNING: terminal is not fully functional > - (press RETURN) > ?column? > ---------- > 1 > (1 row) > > I suspect that psql is unable to determine the screen size > of the "dumb" terminal, and that it's the fault of the terminal > rather than psql. > The warning is displayed by "less" AFAICS. > > There are other psql features like tab-completion that don't work > in this mode because emacs interpret keystrokes first for > itself, in effect mixing emacs functionalities with these of the > application run in the terminal. It's awesome sometimes > and irritating at other times depending on what you expect :) > > OTOH it has also a M-x term command/mode that provides a > more sophisticated screen emulation into which paging seems > to work exactly like in a normal terminal and the emacs key bindings > are turned off. > > > Best regards, > -- > Daniel Vérité > PostgreSQL-powered mailer: http://www.manitou-mail.org > Twitter: @DanielVerite
Joseph Brenner <doomvox@gmail.com> writes:
> I thought I'd reproduced the behavior in an xterm, but I was just
> trying again and I don't see it. It does seem that the dumbness of my
> dumb terminal is a factor.
Evidently.
> If I understand the way this works, it could be an even more baffling
> behavior if I were using an xterm: with a blank PAGER your output
> would disappear only if the select exceeded a certain number of
> lines...
Yeah, that was exactly the behavior I was seeing before fixing it
(the fix is pushed btw).
regards, tom lane