Re: pgAdmin vs. the competition

On Friday 28 March 2008 11:38, Andreas Pflug wrote:
> 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.
>

Yeah, we tried this for awhile in PhpPgAdmin, and eventually through in the
towel; maintaining the code to be able to do cross version schema recreation
was a nightmare. Note phpMyAdmin suffers this problem as well, though they
continue to produce brokenish dumps... we switched to requiring pg_dump,
deciding incorrect dumps were worse than no dumps. Of course if postgres
supplied some type of user space tools for doing this, we'd all be much
happier.

> > 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.

+1 on all counts.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL