Re: More refresh issues
От | Erwin Brandstetter |
---|---|
Тема | Re: More refresh issues |
Дата | |
Msg-id | 46E0B0CB.3000809@falter.at обсуждение исходный текст |
Ответ на | Re: More refresh issues (Dave Page <dpage@postgresql.org>) |
Ответы |
Re: More refresh issues
(Dave Page <dpage@postgresql.org>)
|
Список | pgadmin-hackers |
Hi Dave! Testing the pgAdmin III 1.8.0 Beta 4 (Sep 6 2007, rev: 6608:6622). Client Win XP, host: Debian Etch / PG 8.2.4 and Debian Sarge / PG 8.1.8 I have tested every item of the preceding mail. For brevity I left out what's working. Once again, you only the nagging. :) dpage@postgresql.org wrote: > Erwin Brandstetter wrote: > >> (...) >> There are some more instances, where this is not observed: >> - Changing trigger functions in the table subtree does not update the >> twin instance of the object in the "Trigger Functions" collection. >> > > Yeah, that ones a real pita, and probably not worth the code wart it > would need to fix it. The whole Function under Trigger thing is a kludge > imho :-( > It IS convenient to have the trigger function right there under the trigger node, though. Makes managing triggers a lot more convenient. >> Losing the focus every time a father / grandfather node is updated is a >> rather unwelcome side effect (we talked about it). In the case of a >> large tree the whole tree is moved up and down and, more often than not, >> the focus wanders out of sight. As far as I am concerned, this is way >> more annoying than all of the above. >> > > Fixed :-) > MUCH better now! The tree is also preserved on a manual refresh, which should make Raymond O'Donnell happy, amongst others. :) There is still room for improvement, but these are just minor wishlist items now: - After deleting an object in the table subtree, the focus jumps back to the table node. Ideally, the focus would go to the the nearest brother object or father node. - After creating a new object, the focus would end up on the new object in an ideal world. - When refreshing the database collection, all databases except the maintainance db are closed, and the trees collapsed. Is this necessary for some reason? - The tree is a bit hyperactive at times (going up / down, blanking out), before it settles after changes - especially after deleting objects. That's really a small thing, though. >> - You can also hit <DEL> on the trigger function of a trigger in the >> table subtree, which tries to drop it. But this can never succeed, as >> there is a depending object per definition (the trigger). We might as >> well disable dropping here. >> > > See previous comments about code warts :-( > Well, it is not important. Nothing bad can happen here. New issues: ~~~~~~~~ - Dropping constraints by pressing <DEL> fails, because the dot between schema and table name is missing in the executed SQL (SQL pane is correct, though!): ALTER TABLE myschemamytable DROP CONSTRAINT xxx; Should be: ALTER TABLE myschema.mytable DROP CONSTRAINT xxx; Affects check and foreign key constraints. - Creating a constraint per dialog offers a checkbox "Deferrable". This, however, is only applicable for foreign key constraints. With all other types it produces a syntax error if you use it: ALTER TABLE cpflat.cpkat ADD CONSTRAINT xxx UNIQUE (nummer, katcode) DEFERRABLE INITIALLY IMMEDIATE; http://www.postgresql.org/docs/8.2/interactive/sql-createtable.html says: > > DEFERRABLE > (...) Only foreign key constraints currently accept this clause. All > other constraint types are not deferrable. > - More refresh issues: - After renaming a SEQUENCE, connected tables are out of date. - After renaming a TABLESPACE, all indexes, tables, databases, primary key and unique constraints using are out of date. This actually can have severe side effects. After renaming a tablespace, the combobox "Tablespace" in the properties dialog already uses the new name, but the table still has the old one, so the display defaults to "pg_default". If you use the properties dialog to do anything in such a situation, the table is silently moved to "pg_default". Evil, evil. Maybe it would be a good strategy to perform a refresh on objects right before opening the properties dialog? This would certainly take care of the above situation. I think we have identified most things now, but there may be more. This is a bit of a can of worms. :( - A related case: When you refresh any part of the tree manually, changes may turn up, while other objects, which are also affected, keep their obsolete status. If you have a way to probe for changes, this might be easy to catch. Otherwise it may be tricky / expensive. For instance .. .. if you refresh the sequence collection, in theory, you would have to refresh all table objects connected with a sequence. .. if you refresh any part of the table subtree, you would always have to refresh the table as well. (This should be easy, actually.) .. if you refresh the Trigger Functions collections -> all tables with triggers. .. more cases This is an even bigger can of worms. It is probably better to just leave it to the user and not try to cascade manual refreshes. Regards Erwin
В списке pgadmin-hackers по дате отправления:
Следующее
От: Erwin BrandstetterДата:
Сообщение: Re: Crash when trying to create new database via dialog