Re: More refresh issues
От | Dave Page |
---|---|
Тема | Re: More refresh issues |
Дата | |
Msg-id | 46E0236E.1090803@postgresql.org обсуждение исходный текст |
Ответ на | More refresh issues (Erwin Brandstetter <brandstetter@falter.at>) |
Ответы |
Re: More refresh issues
|
Список | pgadmin-hackers |
Erwin Brandstetter wrote: > Hi developers! > > Testing the pgAdmin III 1.8.0 Beta 4 (Sep 4 2007, rev: 6608:6609). > Client Win XP, host: Debian Etch / PG 8.2.4 and Debian Sarge / PG 8.1.8 > > When making changes via properties dialog, the new policy is to update > _all_ affected places in the object tree. Did I get that right? > > 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 :-( > - Changing / Dropping UNIQUE constraints does not update the table node. > (This worked in the last beta. Though adding comments works now!) > Could not test this for adding a new UNIQUE constraints due to the > crash I reported earlier. Fixed. > - Adding / Changing / Dropping rules does not update the table node. Fixed. > 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 :-) > Other quirks: > - When hitting <DEL> on a collection in a table subtree, the focus jumps > back to the table node (although the "drop" icon in the menu bar is > disabled for collections). Looks like it it trying to refresh the table > node. It should do nothing, like it does on collection nodes outside the > table subtree. Fixed. > - 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 :-( I've uploaded a binary to http://developer.pgadmin.org/~dpage/pgadmin3.zip - would appreciate it if you could check I haven't inadvertently broken anything else!! Thanks,Dave
В списке pgadmin-hackers по дате отправления: