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
