Thread: Forks of pgadmin3?

I know I'm late to the party, but we're only now migrating from
Postgres 9.x, realizing that pgadmin3 does not support Postgres 11.

I have checked out pgadmin4, but I don't like it at all. My colleagues
feel the same way, and some web searching suggests that we are not
alone.

So I wonder if there are any active forks of pgadmin3?

I found some on Github with some significant changes that I assume
were done by people working for VK, the Russian social network. These
appear to be personal hacks though (monosyllabic commit messages, build
scripts added with hard coded local paths etc.).

There are also the Debian packages that have patches adding Postgres
10 support among other things. Not sure if there would be interest
there in continuing to support newer Postgres versions.

Are there other, more organized efforts to continue pgadmin3?

Are there technical reasons why such a continuation would not make
sense?

Cheers,
Christian

-- 
Christian Henz
Software Developer, software & vision Sarrazin GmbH & Co. KG

> On Mar 22, 2019, at 10:56 AM, Christian Henz <c.henz@software-vision.eu> wrote:
>
> I know I'm late to the party, but we're only now migrating from
> Postgres 9.x, realizing that pgadmin3 does not support Postgres 11.
>
> I have checked out pgadmin4, but I don't like it at all. My colleagues
> feel the same way, and some web searching suggests that we are not
> alone.
>
> So I wonder if there are any active forks of pgadmin3?

There's the BigSQL fork, which had at least some minimal support
for 10. I've no idea whether it's had / needs anything for 11.

>
> I found some on Github with some significant changes that I assume
> were done by people working for VK, the Russian social network. These
> appear to be personal hacks though (monosyllabic commit messages, build
> scripts added with hard coded local paths etc.).
>
> There are also the Debian packages that have patches adding Postgres
> 10 support among other things. Not sure if there would be interest
> there in continuing to support newer Postgres versions.
>
> Are there other, more organized efforts to continue pgadmin3?
>
> Are there technical reasons why such a continuation would not make
> sense?
>

It's significant work, and it'd be expended maintaining a fairly mediocre
GUI client.

You might see if you like OmniDB, or one of the other GUI clients, perhaps?

https://wiki.postgresql.org/wiki/PostgreSQL_Clients

Cheers,
  Steve

> Cheers,
> Christian
>
> --
> Christian Henz
> Software Developer, software & vision Sarrazin GmbH & Co. KG
>
>

Jeff Janes <jeff.janes@gmail.com> writes:

> On Fri, Mar 22, 2019 at 8:04 AM Steve Atkins <steve@blighty.com> wrote:
>
>>
>>
>> > On Mar 22, 2019, at 10:56 AM, Christian Henz <c.henz@software-vision.eu>
>> wrote:
>> >
>>
>> There's the BigSQL fork, which had at least some minimal support
>> for 10. I've no idea whether it's had / needs anything for 11
>
>
> I just installed BigSQL's v11 of the database to get the pgAdmin3 that
> comes with it (I couldn't get the Windows installer to install just
> pgAdmin, I had to take the entire server installation along with it) .
> Even though it comes with v11, when you start it says it only supports up
> to v10, and then gives a series of warnings about catalogs and system admin
> functions not being as expected.  Once you are past the warnings, it does
> work at least on the surface, but I have to think some features aren't
> going to work.
>
> Cheers,
>
> Jeff

I think you have little choice other than to give up on pgAdmin3 and any
of the forks. The old pgAdmin3 had become difficult to maintain and I
doubt any fork will be able to avoid this.

I completely understand your frustration with pgAdmin4, though I have
observed significant improvement over the last 12 months. I'm in the
position where I have been prevented from upgrading our databases
because nobody on our team likes pgAdmin4 and they don't want to give up
on pgAdmin3. The proverbial tail wagging the dog if you ask me.

I have looked at some alternatives and have found that

1. dbeaver https://dbeaver.io/download/ is not too bad and is free
2. dataGrip from Atlasian is pretty good, but has a paid license
3. Most of our developers use Visual Code as their editor and it has
some pretty reasonable extensions which makes doing basic database
queries and display of results pretty reasonable and provides OK code
completion support.

Datagrip and visual code also have git integration, which is good if
your keen on DDL stuff being tracked and versioned in git.

Based on the improvements I've seen in pgAdmin4, I suspect it will get
to a usable and stable state eventually and will likely be a pretty good
replacement for pgAdmin3. However, currently, I find it still a little
too unstable.

Personally, I'm pleased I spent the time to get my Emacs and psql
integration working to the point that I do 90% of what I need in psql

-- 
Tim Cross

Am 23.03.19 um 01:36 schrieb Jeff Janes:
> On Fri, Mar 22, 2019 at 8:04 AM Steve Atkins <steve@blighty.com
> <mailto:steve@blighty.com>> wrote:
> 
>     There's the BigSQL fork, which had at least some minimal support
>     for 10. I've no idea whether it's had / needs anything for 11
> 
> I just installed BigSQL's v11 of the database to get the pgAdmin3 that
> comes with it (I couldn't get the Windows installer to install just
> pgAdmin, I had to take the entire server installation along with it) . 
> Even though it comes with v11, when you start it says it only supports
> up to v10, and then gives a series of warnings about catalogs and system
> admin functions not being as expected.
>  

I had found their pgadmin3 page
(https://www.openscg.com/bigsql/pgadmin3/) before, but the source link
there gives a 404, so I thought it may be obsolete.

I also did not find any other links to sources on their page (other than
links back to the upstream projects).

Greetings,
Christian

-- 
Christian Henz
Software Developer, software & vision Sarrazin GmbH & Co. KG

kpi6288@gmail.com schrieb am 22.03.2019 um 17:25:
> 95% of my time I use pgadminIII just to type select and update
> statements and review the output rows.
> 
> I know that I can do this in psql but it’s not handy with many
> columns.

An alternative you might want to try is SQL Workbench/J: https://www.sql-workbench.eu/

Full disclosure: I am the author of that tool. 

It's a cross DBMS tool, but my primary focus is Postgres. 

It focuses on running SQL queries rather then being a DBA tool.

Regards
Thomas

Thanks for the link but we're very reluctant to use Java based programs.
The main reason is that we need to do some works on servers whose admins simply do not allow to install Java.
The screenshots look very promises, however.

Regards
Klaus

> -----Ursprüngliche Nachricht-----
> Von: Thomas Kellerer <spam_eater@gmx.net>
> Gesendet: Montag, 25. März 2019 12:06
> An: pgsql-general@lists.postgresql.org
> Betreff: Re: Forks of pgadmin3?
>
> kpi6288@gmail.com schrieb am 22.03.2019 um 17:25:
> > 95% of my time I use pgadminIII just to type select and update
> > statements and review the output rows.
> >
> > I know that I can do this in psql but it’s not handy with many
> > columns.
>
> An alternative you might want to try is SQL Workbench/J: https://www.sql-
> workbench.eu/
>
> Full disclosure: I am the author of that tool.
>
> It's a cross DBMS tool, but my primary focus is Postgres.
>
> It focuses on running SQL queries rather then being a DBA tool.
>
> Regards
> Thomas

kpi6288@gmail.com writes:

> Thanks for the link but we're very reluctant to use Java based programs.
> The main reason is that we need to do some works on servers whose admins simply do not allow to install Java.
> The screenshots look very promises, however.
>
> Regards
> Klaus
>
>> -----Ursprüngliche Nachricht-----
>> Von: Thomas Kellerer <spam_eater@gmx.net>
>> Gesendet: Montag, 25. März 2019 12:06
>> An: pgsql-general@lists.postgresql.org
>> Betreff: Re: Forks of pgadmin3?
>>
>> kpi6288@gmail.com schrieb am 22.03.2019 um 17:25:
>> > 95% of my time I use pgadminIII just to type select and update
>> > statements and review the output rows.
>> >
>> > I know that I can do this in psql but it’s not handy with many
>> > columns.
>>
>> An alternative you might want to try is SQL Workbench/J: https://www.sql-
>> workbench.eu/
>>
>> Full disclosure: I am the author of that tool.
>>
>> It's a cross DBMS tool, but my primary focus is Postgres.
>>
>> It focuses on running SQL queries rather then being a DBA tool.
>>
>> Regards
>> Thomas

You may not need to install anything on the server. GUI based tools
like dbeaver (also java) and I suspect this one, just run on your
desktop/laptop. You connect to the remote DB as normal i.e. port 5432.

If your network environment is locked down to only allow connections to
port 5432 from specific servers and localhost (i.e. the server), then
SSH can work. You use an SSH tunnel to tunnerl traffic for port 5432 to
a local port and then configure the connection as a local connection
using that port e.g.

in one terminal ssh -L 3330:localhost:5432 db.server

in local software tool, configure the connection with host localhost and
port 3330. It may also be necessary to setup proxy connections if the
host your allowed to connect to is not the db host, but many tools
support this as well as it is a common restriction. You can also use ssh
here, but it is a little more complicated, but same principals.

BTW, the blanket restriction on java runtime is IMO misguided. There is
nothing inherently more risky about the Java runtime than anything else
(python, perl, ruby, node, etc). In fact, the JVM is a pretty decent bit
of kit. The Java language is horrible to work with, but that is a
different issue.

There are some bloody awful Java applications out there, but this really
means, assess on a per app basis, not a blanket ban on all of
them. There are insecure and poorly written apps in every language.

Tim

--
Tim Cross

Dave Cramer schrieb am 25.03.2019 um 22:33:
> Thomas,
> 
> Any chance it would run under graalvm getting rid of the need for the JVM ?
> 
> Dave Cramer

It's hard to tell, but I'd say about 70-80% of my users use Windows, so GraalVM is not an option.

I also can't bundle it for non-Windows users as the GPL license is incompatiable with the Apache License (one reason I
can'tbundle the JVM with it either).
 

Thomas

Re: Jeff Janes 2019-03-23 <CAMkU=1zRvU5x1TAQNiXZK4sgjw1-AyWaFWAosdo7qujB7n7ijQ@mail.gmail.com>
> On Fri, Mar 22, 2019 at 8:04 AM Steve Atkins <steve@blighty.com> wrote:
> > > On Mar 22, 2019, at 10:56 AM, Christian Henz <c.henz@software-vision.eu>
> > There's the BigSQL fork, which had at least some minimal support
> > for 10. I've no idea whether it's had / needs anything for 11
> 
> I just installed BigSQL's v11 of the database to get the pgAdmin3 that
> comes with it (I couldn't get the Windows installer to install just
> pgAdmin, I had to take the entire server installation along with it) .
> Even though it comes with v11, when you start it says it only supports up
> to v10, and then gives a series of warnings about catalogs and system admin
> functions not being as expected.  Once you are past the warnings, it does
> work at least on the surface, but I have to think some features aren't
> going to work.

The BigSQL pgadmin3 "LTS" thing is a giant marketing hoax. Their patch
consists of 90% replacing the original logo with their own version.
The rest is mostly more re-branding, and then a tiny fraction of the
patch establishes compatibility with PostgreSQL 10.0. They fumbled the
version check, so it will complain about incompatibilities if you run
it against 10.1 or any later version.

The Debian pgadmin3 package has patches that actually work, also
available on apt.postgresql.org. I don't claim that it is "supporting"
PG10/11 in the sense that it knows about all features, but all the
warnings on startup are properly avoided. Some day, I should build
RedHat/Windows packages from that and put them somewhere...

https://salsa.debian.org/postgresql/pgadmin3/tree/master/debian/patches

Christoph