Looking back on the order of events, I think it went like this: Back in around May, I was annoyed at pager behavior and wanted to get rid of them-- I tried a blank PAGER setting in my .bashrc (and forgot about it). I also noticed the psql option "\pset pager off". For not particular reason, it didn't occur to me to just put that in a .psqlrc file, and instead I had it in a command-line alias: alias psql="psql --pset='pager=off'" Then more recently I started experimenting with a new build of 9.6.1: The behavior at that stage looked like a difference between 9.4 (run with a bare "psql") and 9.6 (run using a path to the new build). Then later, as I was experimenting with multiple postgres installations, I got more careful about using paths to make sure I knew which one I was running. That cut the alias out of the picture, and the .bashrc setting took over: The behavior at that stage looked like a difference between user login 'doom' and 'postgres'. I kept chasing after obscure file permissions settings or postgres internal permissions (maybe there was something about the new row level security features?), and so on. The folks here kept assuming it had to be some kind of version skew cross-talk between the different installations. Something I'd thought of vaguely (and wish I'd tried) was just creating a new user and trying to reproduce the behavior in a clean account set-up (there are always options to suppress rc files for testing, but suppressing .bashrc isn't that simple). The next thing on the list for me was to remove everything except the new 9.6.1 pgdb binary install: by itself that wouldn't have gotten any closer to isolating the problem, but it would've eliminated some distractions. Oddly enough, if I'd been reading up-to-date pg docs, I might not have tried the .psqlrc setup that pointed the finger at the pager situation: that was just something I was doing on the side, and I didn't think it'd have any effect on a --command invocation, so I didn't worry about it. So yeah, some better messaging when PAGER is mangled wouldn't hurt, if that's possible. Falling back to "pager off" would make sense to me. On Mon, Dec 5, 2016 at 9:28 PM, Joseph Brenner <doomvox@xxxxxxxxx> wrote: > Well yeah, trying to run a PAGER that's not there might throw an error. > Or you know, nothing in PAGER might imply "pager off". > >> I find it a bit odd that all of your queries were using the pager...did I miss where you reported that setting? > > I didn't report it because I wasn't looking in that direction. A > PAGER set to blank for login 'doom' and no PAGER setting for login > 'postgres' explains much of what I was seeing, I think: selects run as > 'doom' tended to be blank (unless I had a pset no pager somewhere), > selects run as 'postgres' always worked. > > > > > > > On Mon, Dec 5, 2016 at 9:03 PM, David G. Johnston > <david.g.johnston@xxxxxxxxx> wrote: >> On Mon, Dec 5, 2016 at 9:53 PM, Joseph Brenner <doomvox@xxxxxxxxx> wrote: >>> >>> And I guess I did that intentionally, my .bashrc has >>> >>> # I use emacs shells, I got a "pager" already: >>> export PAGER='' >>> >> >> PAGER= psql --pset=pager=always -c 'select 1;' >> <nothing on the screen> >> >> Remove PAGER= and I'm good. >> >> I guess that psql could be a bit more helpful by reporting something to >> stderr if the value of PAGER is not an executable (platform dependent...) >> >> I find it a bit odd that all of your queries were using the pager...did I >> miss where you reported that setting? >> >> David J. >> -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
