Re: Editable resultset - Mailing list pgadmin-support
From | Guillaume Lelarge |
---|---|
Subject | Re: Editable resultset |
Date | |
Msg-id | 1361645645.15634.89.camel@localhost.localdomain Whole thread Raw |
In response to | Re: Editable resultset (Dave Page <dpage@pgadmin.org>) |
List | pgadmin-support |
As I'm trying to get back as I now have some time, I just discovered this mail. On Mon, 2013-01-21 at 11:08 +0000, Dave Page wrote: > On Mon, Jan 21, 2013 at 10:50 AM, Michal Kozusznik > <kozusznik.michal@ifortuna.cz> wrote: > > On 17.1.2013 16:54, Dave Page wrote: > >> > >> It's not a case of voting I'm afraid. It's finding someone with the > >> time and desire to implement the feature. > >> > > > > When team working on pgAdmin will get rid of all bugs (hope it is not > > infinity collection) then they may start on improving the product. > > I know pgAdmin is open source and its for free. But it is not reason to > > answer this way. I noticed that any improvement request is rejected with > > comment "do it your self". In my opinion it's a shame. > > Well, much as I'd love to have the time to implement every worthwhile > feature that people request, I simply don't, and I know Guillaume > doesn't either. That's true. > So, there really isn't much I can do other than to > suggest contributing code yourself. That is, after all, how all of us > got involved with PostgreSQL, so you'll have to excuse me for not > thinking it's particularly weird. > Agreed. > > It's quite clear that some features are just unfinished prototypes and no > > one wants to touch this again (being afraid to crash it completely). > > There are 2 features where that sort-of but not quite applies. The > Query Builder, which was half-baked and never should have been > committed in my opinion - what is disabled by default in any build, > and only affects anything if you explicitly enable it, I suppose you mean the Database Designer? because the Query Builder is enabled by default, and is quite stable. > and second, the > Debugger which has never been as stable as it should be, something > which only came to light *after* Mac and Solaris builds were tested > where it became apparently that the threading code in it doesn't work > consistently across all platforms (and that code comes from > wxWidgets). > I tend to disagree. Seems a good enough feature. But I don't use it daily, and not on Solaris or Mac. > But, I've had one of the team at EnterpriseDB working tirelessly for > the last 2 - 3 months to rewrite that from the ground-up for the next > release. > Good :) > > Unfortunately it tells everything about quality of code. But one day it must > > be refactored and some features must be cleaned up. So why to not start > > improving pgAdmin today? Is it really matter of time or desire (rather > > reluctance)? > > Yes, it's time, and lack of people willing to contribute to the > project. And the fact that there are hundreds of thousands of lines of > code, and more features being added to PostgreSQL all the time which > also need to be supported. > Same for me. Lack of time since six or so months. Would love to get back on track. And get help from other contributors. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
pgadmin-support by date: