short post - pspg is ready for release
https://github.com/okbob/pspg. Please, test.
posted by Pavel Stěhule @ 1:40 AM
18 Comments
Pavel Stehule's blog
Some notes about PostgreSQL
Tuesday, September 12, 2017
Previous Posts
- Article about migration from Oracle to PostgreSQL ...
- New Ora2pg is available
- short update: please, test pspg
- PostgreSQL pager pspg is ready to work
- Postgres Pager (pager designed for psql)
- new packages in community repository
- replace_empty_string
- New version of PLpgSQL_check
- Orafce and plpgsql_check are ready for PostgreSQL 10
- How to find unindexed foreign keys
Subscribe to
Posts [Atom]
18 Comments:
Hi there, thanks for your efforts, I compiled commit 9226ea543d23 and can say it does work (I didn't look long for any new stuff though).
I may have a biggy, though; I do a lot of Chinese database stuff and pspg is a godsend to me. However I realized that column alignments are regularly out of sync as soon as double-width characters are displayed. I'm not sure but wasn't it the case that they do align just fine, as they do in 'most' (but sadly not in 'less')?
I've been working on so many things in the meantime so my memory could be wrong.
I could supply some test data if you think you might work on that. Double-width characters do work in 'most', as I said, so that is proof it is in principle feasable.
I am using Czech chars in UTF8 encoding and there are not issues, please, recheck - ncursesw should be used if you are using wide chars.
I used
gcc pager.c -o pager -L. -lncursesw
to compile like I did before. Czech chars and everything outside of 7bit ASCII is one problem, but the other one is graphically wide characters.
Some time ago I published https://github.com/loveencounterflow/to-width which uses a bunch of helpful Unicode-aware packages (sindresorhus/string-width and martinheidegger/wcstring which you find on npmjs.org and github) to achieve constant-width output in the presence of mixed narrow (single-cell) and wide (double-cell) codepoints.
I think the screenshot demonstrate quite nicely what I'm talking about. I could give you a bunch of *.sql files to feed into a test database if that is helpful (in case you want to take up the challenge at all).
please, send me a test case. Maybe the issue is on psql side, maybe in psps.
Here you go:
https://github.com/loveencounterflow/fwtest
Hope it helps,
cheers
I started new issue - https://github.com/okbob/pspg/issues/19
Although there are still some artefacts for horizontal scrolling (maybe due wrong calculation display len) it is much better.
Very nice. Thanks!
It seems that pspg currently does not handle window resizing.
@PL - It is working somewhere. Looks like not everywhere ncurses mechanism is working. When I call psql and pspg locally, then it is working. When I use ssh it doesn't work. It can be related to ncurses version too.
Pavel,
Even when I run locally, it doesn't work for new query after resizing.
What ncurses version do you use? I have not a problem with ncurses 6 - ncurses-6.0-8.20170212.fc26.src.rpm
I use libncursesw5-dev on Ubuntu.
probably this is a reason. The resizing there doesn't work well when the application is nested. You can try direct call of pspg (without psql) by pspg -f somefile. Is resizing working there?
Hm, without psql it working.
Here my actions:
1. run select * from pg_class to start pspg
2. Resize terminal window
3. After resizing pspg still correctly working with this query!
4. Stop pspg (by pressing q)
5. Run another query and pspg stops working correctly
6. When restarting psql, pspg works correctly again.
It is strange. Any new query means new instance of pspg. So when you stop pspg, then it is finished, and with new query, then it should to get fresh window size. So it looks like the core of the issue will be else where. What is psql version? Some older psql clients had a issue with resizing.
Yes, you are right!
The issue on a psql 9.4
With psql 9.6 worked fine.
I tested pspg on an up to date Debian 9 with Pg 9.6.
I compiled it with just a simple make. It works as expected.
I have found just a small typo: The error message for -s states that there are only 11 colour schemas while in the program there are 12.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home