Re: pgAdmin vs. the competition
От | Robert Treat |
---|---|
Тема | Re: pgAdmin vs. the competition |
Дата | |
Msg-id | 200804012121.23947.xzilla@users.sourceforge.net обсуждение исходный текст |
Ответ на | Re: pgAdmin vs. the competition (Andreas Pflug <pgadmin@pse-consulting.de>) |
Список | pgsql-advocacy |
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
В списке pgsql-advocacy по дате отправления: