Skip site navigation (1) Skip section navigation (2)

Re: More refresh issues

From: Erwin Brandstetter <brandstetter(at)falter(dot)at>
To: dpage(at)postgresql(dot)org
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: More refresh issues
Date: 2007-09-07 02:00:43
Message-ID: 46E0B0CB.3000809@falter.at (view raw or flat)
Thread:
Lists: 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(at)postgresql(dot)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


In response to

Responses

pgadmin-hackers by date

Next:From: Erwin BrandstetterDate: 2007-09-07 02:04:02
Subject: Re: Crash when trying to create new database via dialog
Previous:From: Dave PageDate: 2007-09-06 19:27:52
Subject: Re: Tablespaces for indexes, tables and databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group