Re: Select works only when connected from login postgres

> Agreed. One thing that would be very simple is to treat an empty PAGER
> value the same as "unset".

Sounds excellent.

> 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

So the empty PAGER value case is the only one that doesn't seem
covered already. (I'm talented about finding these things...)

On Tue, Dec 6, 2016 at 9:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Joseph Brenner <doomvox(at)gmail(dot)com> writes:
>> Looking back on the order of events, I think it went like this:
>> [ careful postmortem ]
>
> Thanks for following up!
>
>> 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.
>
> Agreed. One thing that would be very simple is to treat an empty PAGER
> value the same as "unset". Detecting whether a nonempty value is behaving
> sanely seems a great deal harder; depending on what pager you're using
> and how you stop it, nonzero exit codes from the called process might
> be normal. I think it might be practical to issue a warning if we get
> an exit code of 126 or 127, though. We have a comment in archive-command
> invocation:
>
> * Per the Single Unix Spec, shells report exit status > 128 when a called
> * command died on a signal. Also, 126 and 127 are used to report
> * problems such as an unfindable command; treat those as fatal errors
> * too.
>
> The relevant text in POSIX is
>
> If a command is not found, the exit status shall be 127. If the
> command name is found, but it is not an executable utility, the
> exit status shall be 126. Applications that invoke utilities
> without using the shell should use these exit status values to
> report similar errors.
>
> I don't believe we want to complain about exit on a signal, because
> SIGTERM or SIGINT is a typical exit in some pager setups. But these
> two codes strongly suggest something broken about your PAGER value.
>
> So I propose
> (1) ignore PAGER if it's an empty string
> (2) if pclose returns exit code 126 or 127, report that the PAGER
> command didn't work. I'm not sure how complex that is, because IIRC
> the pclose is at some remove from the popen call, but if it's not
> unreasonably hairy we should do it.
>
> regards, tom lane