Re: pgAdmin vs. the competition

Guillaume Lelarge wrote:
> Greg Smith a écrit :
>> [...]
>> For starters it seems to lack UI elements that have been in the GUI
>> world since Windows 3.11.
>
> I think crossplatform development doesn't help on this issue. And
> wxWidgets seems, well, less interesting (in the UI) than Qt for example.
>
>> Whenever PostgreSQL is busy the UI fails to give any clue, no icon
>> changes to a spinning hourglass, no status bar filling up, not even a
>> mindless pop-up saying "busy...".  This is painfully obvious when
>> doing a BACKUP or RESTORE.
>
> For the backup/restore stuff, I don't think pgAdmin can actually do
> something better. We heavily rely on pg_dump/pg_restore. Any other UI
> tool would need to do the same.
It IS possible to do better, 'though it would be much easier if pgAdmin
didn't need to use pg_dump/pg_restore external processes.

> I completely agree on this. pgAdmin is really far far far away from
> SQL Manager. But they have many more developers than us, and they
> don't have to handle crossdevelopment. We need to show our differences
> : remote configuration, Slony support, etc. Adding pgPool, pgPool-II
> and pgBouncer support would be great and is something I would like to
> add as soon as possible.
IMNSHO a persistent problem is the somewhat restricted view of
developers of additional needs, i.e. there's no good support in the
tools for re-usage. Examples:
The request for pg_dump/pg_restore functionality in a library is quite
old. Controlling the processes isn't too much fun when doing
cross-development.
Slony capsules its operations in the slonik executable as well, in a
very unix-like fashion. Slony support in pgadmin is mostly a
re-implementation, a reinvention of the wheel.

Both could provide a library, with the executables just being a thin
shell around it (converting cmd line/config file params to config
structures handled over to the lib). Same problem will probably arise
with pgPool et al.

Regards,
Andreas