Re: Release plan - Mailing list pgadmin-hackers
From | Dave Page |
---|---|
Subject | Re: Release plan |
Date | |
Msg-id | 50056.80.177.99.193.1051724456.squirrel@ssl.vale-housing.co.uk Whole thread Raw |
In response to | Re: Release plan (Andreas Pflug <Andreas.Pflug@web.de>) |
Responses |
Re: Release plan
|
List | pgadmin-hackers |
It's rumoured that Andreas Pflug once said: > Dave Page wrote: > >>Preview/Developer Releases >>-------------------------- >> >>These are useful to get feedback during the development phase. >>Basically unsupported, and may be missing features, the idea is to get >>feedback as we go, and find any major problems early on that may not be >>spotted by us. We can release these following any major commits or task >>completions. >> > That's what I'm offering at the moment at > www.pse-consulting.de/pgadmin3/pgadmin3.zip. Maybe we should have a > more official place for this? We can add it to the pgAdmin downloads page. I'll probably do a simple installer as well. >>2) Property editor/Creation dialogues for each object type. >> > Well, seems like a punishment to me... Do we really need ALL objects > supported for a release? I believe for the first step we could reduce > it to the most used object types, omitting rarely used ones. Virtually > nobody will miss a Operator Class wizard... > > Here is my ranking with descending priority: > - User (done) > - Group > - Table > - View > - Index > - Foreign Key > -- up to here, absolutely necessary for Beta-1, covers >90 % or work. > --------------------------- > - Function > - Trigger > - Rule > - Sequence > - Check > -- coverage >99 % with this objects > --------------------------- > - Type > - Domain > - Operator > - Aggregate > - Conversion > - Schema > - Language > - Database > - Cast > - Operator Class Don't forget that Foreign Keys and Checks are part of the table dialogue (remember pgAdmin II?). We *cannot* release without being able to create databases and schemas (how would a new server get populated without using SQL?) imho, and I'd also like to see Domains done as they are seriously useful, even to the novice. How painful are these to produce really anyway? In pgAdmin II the hard bit certainly wasn't the dialogues, but I guess the IDE for VB is a little more useful for that. >> >>3) Table viewer/editor, with data save/export capable of handling a few >>basic ASCII formats. >> > Which formats are needed? > - CSV, with selectable separator, escape char, string delimiter, line > delimiter That'll cover just about everything. In the future I would like to add XML and HTML page (title, plus table). > - ? > >>4) Combined query tool, switchable between pure SQL entry and QBE >>modes, with data save/export capable of handling a few basic ASCII >>formats. >> > Export: same question as above. Yup, let's use the same code. >>Thoughts, comments? >> >> > I totally agree to keep pgAdmin3 at a reasonable core functionality. > Still, some maintenance tools for daily work should be included in the > next release. VACUUM is one of them, and database backup and restore is > just the same level. VACUUM is essential, but is trivial to do anyway. Database backup and restore is not something I ever want pgAdmin to do - people will use it in production, and it'll be too easy for us to get something wrong. At a push I'd grudgingly do a frontend for pg_dump. Regards, Dave
pgadmin-hackers by date: