Re: Select works only when connected from login postgres

From: Joseph Brenner <doomvox(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Select works only when connected from login postgres
Date: 2016-12-06 21:54:39
Message-ID: CAFfgvXXUL3GPAqskJWdtHPH5W3U12k9t+eFrvj6jTk+7fmW-ow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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(at)gmail(dot)com> 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Joseph Brenner <doomvox(at)gmail(dot)com> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2016-12-06 22:56:54 Re: PDF files: to store in database or not
Previous Message Joseph Brenner 2016-12-06 21:53:08 Re: Select works only when connected from login postgres

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-12-06 21:59:47 Re: Compiler warnings
Previous Message Joseph Brenner 2016-12-06 21:53:08 Re: Select works only when connected from login postgres