Dave Page wrote:
>We can add it to the pgAdmin downloads page. I'll probably do a simple
>installer as well.
>
Do we need this for a preview? It's simply unzipping and double click on
pgAdmin.exe...
>>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?).
>
This is a point of discussion. Should this really be done in one monster
dialog or better be split into separate ones?
>We *cannot* release without being able to create
>databases and schemas (how would a new server get populated without using
>SQL?)
>
Well, since they are simply "CREATE objectType name" to get up and
running...
> 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?
>
So your must-have list for a beta release looks like this:
Group, Table, View, Index, Foreign Key, Check, Domain, Database, Schema
>VACUUM is essential, but is trivial to do anyway.
>
Yup.
>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.
>
I disagree. pgadmin3 should support every day work, and backup/restore
is one part of it. I agree that this is some kind of advanced feature,
available only to superusers after enabling the backup option.
Regards,
Andreas
