Reaction score: 367
Working on this matter now.The successor is pgAdmin4, however, this is not in the ports, and while pre-compiled installation packages are provided for Linux, Windows and macOS, we need to try to get around with the sources, in case we want to have it on FreeBSD. I did not try this yet.
That said, pgAdmin4 is a totally different animal than ...3. Actually it provides a web interface to the databases, and the desktop version comes with its own web server in order to achieve this - quote from the documentation:
As I consider postgres being just perfect - it never failed me, and also working with the dev guys on the list is wonderfully constructive - and finding pgadmin3 the magic looking glass to see whats going on inside, I'm currently figuring out how to tackle with that pgadmin4.
What I can say so far: pgadmin4 is designed with an entirely different architecture in mind. It is not an application to be installed on some computer and then run by the user(s) on that computer.
Instead, it seems to be an almost fullsize Web Application Server, designed to run on an arbitrary application server machine, being connected as the middleware by a frontend Web Server (probably running on some other machine), utilizing it's own user administration (just like a website) and then accessing some postgres installations (likely yet on other machines).
The underlying Application Framework appears to be Flask utilizing sqlite3 as it's database backend. (A web application server is the middleware between the frontend web server and the backend database. The sqlite3 here is the backend for the application's persistent storage demands, while the postgres to be administered is the application's payload to work with.)
There is no application to compile, as it is all python. (Neverteless the python module prereqs do contain libaries in native C; these are compiled automatically on package install - when things go well.)
Such an application server is usually not installed by root into the system paths. It is rather installed by some user into their homedirs, putting all the (ever changing) module dependencies right alongside into the application.
Certainly such an architecture can also be concentrated to run on a single machine for a single user - but that's not the most easy way to approach it.
It is probably quite difficult to roll such a beast as a port. It is also kind of sisyphos work, because with every release the module dependencies will change - which would normally be no problem as the application itself carries a list of it's dependencies and can install these per script: just put it into a new directory and throw away the old one.
There is also a more serious problem with it: we have the Kerberos integrated in the base system, and postgres also has the Kerberos integrated. So we would never need passwords for the database (and then we cannot store our production database passwords within the application onto github, like other people seem to do). The pgadmin3 would just let libpg grab the Kerberos tickets as when connecting the database directly, so the single-sign-on works transparently, no password needed.
But now pgadmin4 would split this one securely authenticated connection into two unauthenticated and dubious halfes, and we're quite back to herding passwords, for pgadmin4 AND for the database.