But on the other hand, if you've got a blank PAGER envar and a "\pset pager something", the pset should win (just as it does now). On Tue, Dec 6, 2016 at 1:53 PM, Joseph Brenner <doomvox@xxxxxxxxx> wrote: > 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. > > But then, I would say that. > > > On Tue, Dec 6, 2016 at 12:13 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Joseph Brenner <doomvox@xxxxxxxxx> writes: >>>> Agreed. One thing that would be very simple is to treat an empty PAGER >>>> value the same as "unset". >> >>> Sounds excellent. >> >> Actually, after thinking about it a bit longer, should PAGER-set-but- >> empty be treated as equivalent to "pager off", rather than as a request >> to use the default pager? I could see arguments either way for that. >> >>>> Detecting whether a nonempty value is behaving >>>> sanely seems a great deal harder ... >> >>> I was thinking a check for existence and executability, but I guess >>> that's covered already... if you use a random string as PAGER you get >>> a sh error: >> >>> export PAGER="nadatech" >>> /usr/lib/postgresql/9.6/bin/psql --no-psqlrc --dbname=doom >>> --username=doom -p 5434 --host=/var/run/postgresql --command="SELECT >>> 'hello' AS world;" >> >>> sh: 1: nadatech: not found >> >> Hm, so you do; so my thought that this needs explicit code on our end >> seems wrong. [ experiments... ] It seems like the specific case of >> PAGER being empty or all-white-space causes the shell to think that >> it's executing an empty line and just do nothing (in particular, not >> print any error). pclose then returns EPIPE, at least on my platform, >> which we could report but it doesn't seem like a very useful report. >> Any other case seems to provoke a shell complaint that's probably >> sufficient for diagnosis. >> >> So what I'm thinking now is that if PAGER is empty or all white space >> then we should not try to use it as a shell command; we can either >> treat the case as "pager off" or as "use default pager". Everything >> else we can leave to the invoked shell to complain about. >> >> Comments? >> >> regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
