Re: More refresh issues

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