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

On 2020-09-21 11:44, Dave Page wrote:
> Hi
>
> On Mon, Sep 21, 2020 at 4:25 PM Mark Murawski
<markm-lists(at)intellasoft(dot)net <mailto:markm-lists(at)intellasoft(dot)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.