Joseph Brenner writes:
> I thought I'd reproduced the behavior in an xterm, but I was just
> trying again and I don't see it. It does seem that the dumbness of my
> dumb terminal is a factor.
Evidently.
> If I understand the way this works, it could be an even more baffling
> behavior if I were
Yes, I have a tendency to use emacs sub-shells (and occasionally M-x
sql-postgres)--
I thought I'd reproduced the behavior in an xterm, but I was just
trying again and I don't see it. It does seem that the dumbness of my
dumb terminal is a factor.
If I understand the way this works, it could be
Tom Lane wrote:
> BTW, I realized while testing this that there's still one gap in our
> understanding of what went wrong for you: cases like "SELECT 'hello'"
> should not have tried to use the pager, because that would've produced
> less than a screenful of data
At some point emacs was m
Joseph Brenner writes:
> 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.
Yeah, on reflection that argument seems pretty persuasive. So I propose
the attached patch.
B
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 wrote:
> Well, my take would be that if you've taken the trouble to set an
> empty string as the PAGER that means some
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 wrote:
> Joseph Brenner writes:
>>> Agreed. One th
On Tue, Dec 6, 2016 at 1:13 PM, Tom Lane wrote:
> 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 sh
Joseph Brenner 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
> 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 alre
Joseph Brenner 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. On
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 d
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 d
On Mon, Dec 5, 2016 at 9:53 PM, Joseph Brenner 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;'
Remove PAGER= and I'm good.
I guess that psql could be a bi
And I guess I did that intentionally, my .bashrc has
# I use emacs shells, I got a "pager" already:
export PAGER=''
On Mon, Dec 5, 2016 at 8:52 PM, Joseph Brenner wrote:
> Wait, that's not quite right. The user 'postgres' has no PAGER envar,
> but user 'doom' has an empty value:
>
> PAGER=
Wait, that's not quite right. The user 'postgres' has no PAGER envar,
but user 'doom' has an empty value:
PAGER=
On Mon, Dec 5, 2016 at 8:50 PM, Joseph Brenner wrote:
>> So what does:
>>
>> env | grep PAGER
>>
>> show?
>
> Nothing. I have no PAGER settting (I don't normally use one).
>
>
> On
> So what does:
>
> env | grep PAGER
>
> show?
Nothing. I have no PAGER settting (I don't normally use one).
On Mon, Dec 5, 2016 at 5:33 PM, Adrian Klaver wrote:
> On 12/05/2016 05:13 PM, Joseph Brenner wrote:
>
>
>> I just went around temporarily undoing things I did while
>> straigtening up,
Joseph Brenner writes:
> Okay: I think I'm closing in on the trouble. I didn't used to
> have a ~/.psqlrc file, but recently I experimented with
> creating one. When I have a .psqlrc file containing the magic
> incantaion
>\pset pager off
> *Then* everything works.
Ah! So, most likely, t
On 12/05/2016 05:13 PM, Joseph Brenner wrote:
I just went around temporarily undoing things I did while
straigtening up, and I find there's one thing I can do that
consistently breaks things: removing my new ~/.psqlrc file.
In fact, it appears that I need to have a file that exists and
contains
On Mon, Dec 5, 2016 at 6:13 PM, Joseph Brenner wrote:
> Another oddity I noticed is that I expected that the .psqlrc
> file would not be read at all when using the --command feature,
> but instead I would see messaging that indicated the commands
> in there were being executed
New behavior in
Okay: I think I'm closing in on the trouble. I didn't used to
have a ~/.psqlrc file, but recently I experimented with
creating one. When I have a .psqlrc file containing the magic
incantaion
\pset pager off
*Then* everything works. All three of my extant postgresql
installations work correc
Joseph Brenner writes:
>> So what happens when you specify the port in your psql connection, eg:
>> /usr/local/pgsql/bin/psql --dbname=doom --username=doom -p 5432
>> /usr/local/pgsql/bin/psql --dbname=doom --username=doom -p 5433
>> /usr/local/pgsql/bin/psql --dbname=doom --username=doom -p 5434
Adrian Klaver writes:
> My suspicion is that when you did the source build you got some cross
> contamination of libraries.
That's the best theory I can come up with either, although libpq's
APIs haven't really changed in any non-backwards-compatible fashion
in years. I could imagine a newer ps
Yeah, I get the sense I need to simplify the situation, if only to
eliminate some distractions from the story.
This morning I was thinking I want to play around with pg_hba.conf
settings some more, but after that I'll do some pg_dumps and
uninstalls and see how things behave.
Oh, trying:
/usr/
On 12/03/2016 09:38 PM, Joseph Brenner wrote:
So is the 9.4 instance the production/live database?
Essentially, but it's not heavily used: this is me messing around on a dev box.
So what happens when you specify the port in your psql connection, eg:
/usr/local/pgsql/bin/psql --dbname=doom --u
> So is the 9.4 instance the production/live database?
Essentially, but it's not heavily used: this is me messing around on a dev box.
> So what happens when you specify the port in your psql connection, eg:
> /usr/local/pgsql/bin/psql --dbname=doom --username=doom -p 5432
> /usr/local/pgsql/bin/
On 12/03/2016 07:38 PM, Joseph Brenner wrote:
Our story thus far: I've now got three different pg installations, with three
servers running simultaneously:
ps ax | egrep postgres | egrep '\-D'
748 ?S 0:04 /usr/lib/postgresql/9.4/bin/postgres -D
/var/lib/postgresql/9.4/main -c
conf
>For kicks, how about \echo or \! Something that doesn't need a server to work.
Sure: those do work.
doom@tango:~$ /usr/local/pgsql/bin/psql --dbname=doom --username=doom
psql (9.6.1)
Type "help" for help.
doom=# select 'hello' as world;
doom=# \echo 'yo'
yo
doom=# \! ls -lad p*
drwxr-xr-x 1 do
On Saturday, December 3, 2016, Joseph Brenner wrote:
>
> doom=# select 'hello' as world;
> doom=#
>
> Nothing else gives me any output either: \l, \du, etc.
>
>
For kicks, how about \echo or \! Something that doesn't need a server to
work.
David J,
Our story thus far: I've now got three different pg installations, with three
servers running simultaneously:
ps ax | egrep postgres | egrep '\-D'
748 ?S 0:04 /usr/lib/postgresql/9.4/bin/postgres -D
/var/lib/postgresql/9.4/main -c
config_file=/etc/postgresql/9.4/main/postgresql.co
2
Joseph Brenner writes:
> I'm trying to get a new build of 9.6.1 working on Debian
> stable and I'm seeing some odd behavior where things work
> correctly if I run psql when logged in as user 'postgres',
> but if I'm logged-in as user 'doom' (my usual login), I don't
> seem to have any select privi
Yes, and sorry about the re-post. I thought my original message was
hung-up in moderation, so I was doing an unsub/resub fandango to get
email addresses to match.
On Sat, Dec 3, 2016 at 12:13 PM, Adrian Klaver
wrote:
> On 12/03/2016 12:08 PM, Joseph Brenner wrote:
>>
>> I'm trying to get a new
On 12/03/2016 12:08 PM, Joseph Brenner wrote:
I'm trying to get a new build of 9.6.1 working on Debian
stable and I'm seeing some odd behavior where things work
correctly if I run psql when logged in as user 'postgres',
but if I'm logged-in as user 'doom' (my usual login), I don't
seem to have an
I'm trying to get a new build of 9.6.1 working on Debian
stable and I'm seeing some odd behavior where things work
correctly if I run psql when logged in as user 'postgres',
but if I'm logged-in as user 'doom' (my usual login), I don't
seem to have any select privileges. Even this fails
silently:
33 matches
Mail list logo
