Thread: psql -f and PAGER
Hello,
I noticed that this runs your pager:
psql -f <(echo 'select * from pg_class;')
but not this:
echo 'select * from pg_class;' | psql
A client encountered this when the psql command run from their deb's
.postinst file started to hang.
We can prevent it with PSQL_PAGER='', but it almost seems like a bug to
me, since I expect -f to be for non-interactive use. I'd at least call
it a footgun.
Indeed running the pager for -f but not stdin seems opposite of the last
line of these docs (https://www.postgresql.org/docs/14/app-psql.html):
> Using this option is subtly different from writing psql < filename.
In general, both will do what you expect, but using -f enables some nice
features such as error messages with line numbers. There is also a
slight chance that using this option will reduce the start-up overhead.
On the other hand, the variant using the shell's input redirection is
(in theory) guaranteed to yield exactly the same output you would have
received had you entered everything by hand.
Does it seem wrong to anyone else to run the pager from -f? Is it
something the community would accept patches to change?
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
On Tue, Mar 29, 2022 at 6:30 PM Paul Jungwirth <pj@illuminatedcomputing.com> wrote:
I noticed that this runs your pager:
psql -f <(echo 'select * from pg_class;')
but not this:
echo 'select * from pg_class;' | psql
Indeed running the pager for -f but not stdin seems opposite of the last
line of these docs (https://www.postgresql.org/docs/14/app-psql.html):
On the other hand, the variant using the shell's input redirection is
(in theory) guaranteed to yield exactly the same output you would have
received had you entered everything by hand.
Does it seem wrong to anyone else to run the pager from -f? Is it
something the community would accept patches to change?
If anything the behavior of the echo is contrary to the documentation (though I get your point about "yield exactly the same output").
For both examples:
pager defaults to on
the output of the psql session is a terminal
the full contents of pg_class are not going to fit on one terminal screen
ergo, the output of select * from pg_class; should be piped to the pager in both cases
I'd be on board with having the documentation better match reality (if we can figure out why echo-pipe is different and it's something we control) but I'm against changing the longstanding behavior to an only subjectively different one.
Seems like both setting pager to off and ON_ERROR_STOP to on should be the first things people do in their psql non-interactive automations (or run them through the "tee" command...). It would be nice to not have to change the pager but I also don't see messing with the default.
David J.
On 2022-03-29 19:08:44 -0700, David G. Johnston wrote:
> On Tue, Mar 29, 2022 at 6:30 PM Paul Jungwirth <pj@illuminatedcomputing.com>
> wrote:
>
> I noticed that this runs your pager:
>
> psql -f <(echo 'select * from pg_class;')
>
> but not this:
>
> echo 'select * from pg_class;' | psql
[...]
>
> For both examples:
> pager defaults to on
> the output of the psql session is a terminal
> the full contents of pg_class are not going to fit on one terminal screen
> ergo, the output of select * from pg_class; should be piped to the pager in
> both cases
This is incomplete in the docs. The pager is also not called if stdin is
not a terminal (which makes sense - you couldn't control the pager).
So
echo 'select * from pg_class;' | psql
doesn't call the pager. Neither do:
psql -f <(echo 'select * from pg_class;') < /dev/null
psql -f <(echo 'select * from pg_class;') > /dev/null
But
psql -f <(echo 'select * from pg_class;')
does, since both stdin and stdout are a terminal.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"