Re: How do I tell pgAdmin 4 to not harass me with pointless extra clicks every single time I want to use it? - Mailing list pgadmin-support

On 2020-09-21 11:44, Dave Page wrote:
 > Hi
 >
 > On Mon, Sep 21, 2020 at 4:25 PM Mark Murawski 
<markm-lists@intellasoft.net <mailto:markm-lists@intellasoft.net>> wrote:
 >
 >     Hi Dave,
 >
 >     What's the difference between the one I'm using now:
 >     deb http://apt.postgresql.org/pub/repos/apt/ buster-pgdg main
 >
 >     And this one?
 >     deb https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/buster
 >     pgadmin4 main
 >
 >
 > They are architected and built in a completely different way. The 
ones in the pgadmin4 repo were developed by me and use a common 
architecture (and in fact, the majority of the build scripts) for both 
Debian and Redhat platforms. They work in much the same way as the macOS 
or Windows packages, shipping a pre-built, private virtual environment 
with all the correct libraries etc. in them.
 >
 > Christoph who maintains the PostgreSQL repo (the one you're currently 
using) prefers to package all the Python dependencies as individual 
packages and install them system-wide. In an ideal world, that would be 
fine, except that there are a lot of dependencies and he sometimes can't 
keep up with security updates etc. that we rely on. We've had similar 
issues with yum.postgresql.org <http://yum.postgresql.org>, so the 
packages we've built ourselves have been designed to avoid these and 
various other design issues that came to light with both the deb and rpm 
packages over the last couple of years.
 >
 >
 >
 >     The reason I'm using http://apt.postgresql.org/pub/repos/apt/ was 
I was
 >     specifically instructed from this list, to use this repository to 
avoid
 >     the issue I'm having right now!
 >
 >
 > That may well have been the case even just a few months ago. Our 
repos are only a few months old, but so far seem to be quite reliable. I 
think we've only had one issue reported related to them since we 
launched, and that turned out to be an environment issue and not a 
packaging bug.
 >
 >
 >     This is one of the things that really bug me... is that the best
 >     practices are constantly changing and this is always a moving 
target to
 >     even get installed.
 >
 >
 > I'm not sure I'd call it a constant change - we changed once, when it 
became clear the original strategy of relying on packagers from 
elsewhere in the community wasn't working and couldn't easily be fixed.
 >



Hi Dave,

It was more like, "if it wasn't one thing, it's another" type 
experience.  Especially trying to keep up with the releases and trying 
to update from pgadmin4 1.x to pgadmin4 1.y and having everything just 
be completely broken and have to basically rm -rf the whole thing and 
troubleshoot for a week get it working again.

I had given up for a long time until I found out about the debian 
repo... which had a slightly higher success rate than running from the 
tarball.

One of my missing features is navigating directly to a trigger function 
from a trigger.

Tables -> Triggers -> <triggername>
You can see the SQL for CREATE TRIGGER, but can't navigate directly to 
the function, so this is a showstopper for me.

Another missing feature is double click on a column header to expand the 
column to fit the data.

Another missing feature is the little DDL window in the bottom left 
corner so you can see DDL while also navigating around.

Another crazy behavior is when trying to organize the layout and move 
things like the SQL/DDL window, it's really difficult to put the SQL 
window back into the original location where Statistics/Dependencies/etc 
is.  I wind up having to do 'reset layout' a lot.  There's just an odd 
lag to the window managment and it also stops working when you run over 
a window border.

Also, if you reset the layout, all of your tabs and connections are 
gone. I might as well have restarted the application entirely... so I 
painstakingly set up my work environment and then with one false move 
adjusting the layout, I have to reset and rebuild from scratch... this 
is a showstopper.

If you close and re-open pgadmin4, none of your work state is saved. Now 
that I've gotten used to omnidb and datagrip, this is now a showstopper. 
  I can't even count how many times I've lost work because I've crashed 
chrome or firefox by doing other dev work in other tabs and lost my 
current state of affairs in pgadmin4.

It looks like Pgadmin4 must run in a browser these days.  It looks like 
the self-contained local-web type of runtime is not available anymore. 
For my workflow, running in a browser just doesn't work at all.

If you close the dashboard or the scratch pad there's no way to get it 
back, unless you reset the layout.  If you wind up losing the Browser 
window in the layout, there's no way to get it back without resetting 
the layout.

Oddity: Sometimes 'esc' doesn't get you out of menus and other popouts. 
Example: open up Tools, click inside a console window, and then hit 
'esc'... nothing happens

Copy from a table has a bit to be desired... why does a copy of multiple 
columns concatenate all the values together?  Why not put a comma in 
between values?

Not sure if this is possible inside a browser, but ctrl-w doesn't close 
the tab you're working on... it closes the *browser* tab, which 
thankfully gives you a warning.

You cannot edit the label of a tab of a query window

'Detach Panel' of a query console pops up a completely blank, 
non-functional window.

When dragging a detached window tab around.. it sometimes gets 'stuck' 
and cannot cover the 'Browser' component, depending on the layout.

It's also sometimes difficult to actually grab the component handle to 
try and move it in the layout.