Re: pgadmin III initial comments and bug reports - Mailing list pgadmin-hackers
From | Andreas Pflug |
---|---|
Subject | Re: pgadmin III initial comments and bug reports |
Date | |
Msg-id | 3F0C58FF.6000702@pse-consulting.de Whole thread Raw |
In response to | pgadmin III initial comments and bug reports (Troels Arvin <troels@arvin.dk>) |
List | pgadmin-hackers |
Troels Arvin wrote: >- I tried to create a relatively simple table, but > the resulting SQL failed because of misplaced and/or > missing commas: > > Fixed (invented last night when implementing table inheritance) > - I tried opening the "Query builder", but got a debug window: > src/gtk/window.cpp(2852): assert "(m_widget != NULL)" > > I finally commented out the query builder menu entry completely, not only for release builds. This bug is really-really-really-well-known, and documented in BUGS.txt, but nobody reads it... In case anybody's going to debug that beast, please be invited to uncomment the menu and get it running. >- When adding a new column ("New Column" dialog), I'm not > allowed to bring focus to neither the "Length" or the > "Precision" fields, so the varchar length cannot be > specified. This seems to be a general problem for all > types with lengths which may be defined. > > Typo disabling all length types, fixed. >Some inconveniences: > > - I have to explicitly name primary keys which is annoying > because I normally don't care what primay keys are called. > Fixed (was implemented and got lost) > It would be cool if pgadmin had pre-selected a name with > a pattern as <table_name>_pkey as suggested primary key name. > Not necessary, if name is empty PostgreSQL will do this. > - When creating a new table, it's inconvenient that the > primary key has to be defined separately. Example: > In the CLI, I would do: > create table test(test_id int not null primary key, ...); > i.e. define the primary key in connection with the column > which will act as primary key. > It would be great of pgadmin had a selection box called > "primary key" in the "Create column" dialog when a > primary key hasn't already been defined for the table. > We can put this on the wishlist. Not so trivial because we want to inhibit duplicate pk definition. > - Indexes related to primary keys are not listed under > the table's "Indexes" sub-tree. > The PK is a special unique index, which is listed under constraints. It can't be handled like an ordinary index, so I'd consider it wrong if it was listed there. > - Foreign keys have to be explicitly named which is a bit > annoying compared to the CLI situation where PostgreSQL > just chooses a name like $1, $2, ... > No, they don't. > - When creating a new column, I cannot simultaneously > to look at another column in another table to be > inpired by data type, etc: The "New Column" dialog > is "modal". > I hate modal dialogs, but need this in that situation to prevent problems. I'll keep this in the back of my mind. >Finally, a feature suggestion: > > - I haven't been able to find a sort of front-end to > pg_dump. It would be nice if that existed in pgadmin. > > On my wishlist too. You'll have to wait for V2... Regards, Andreas
pgadmin-hackers by date: