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:

Previous
From: Kozusznik Michal
Date:
Subject: Re: backup improvements
Next
From: Guillaume Lelarge
Date:
Subject: Re: backup improvements