Hi Dave!
dpage@postgresql.org wrote:
> (...)
>
> Erwin; I'm somewhat wary of fixes in the treeview refresh code as there
> can be odd corner cases caused by the relationships between some object
> types. If I get you an updated exe, would you mind running it though
> it's paces to help check I didn't miss anything?
Sure, I'll see what I can nag. :)
Actually, I've had a posting on this very subject in my draft folder for
some time. I was just not sure what's the best course of action to propose.
I'll append it here, just in case.
brandstetter@falter.at did not yet write:
> Hi developers! Hi Dave!
>
> Testing the new snapshot: pgAdmin III 1.7.0 (Jun 22 2007, rev:
> 6379:6385). Client Win XP, host: Debian Sarge / PG 8.1.8
>
> When making changes to achild element of a table (column, index, ...)
> in the properties dialog, the SQL pane for the object is being
> refreshed immediately. However, the SQL pane for the table is not
> refreshed at the same time. We end up with updated SQL for the child
> element but obsolete SQL for the table. This is sort of confusing.
>
> I think it should be all or nothing in this case, with a preference on
> "all": refresh the SQL pane for the table as well.
>
> Of course we have to take into account a manual refresh on a child
> elements as well. If you have an easy way of checking whether the
> refresh has brought anything new, you might cascade the refresh to the
> table. We might end up with updated SQL for the table and for the
> initiating child element, but obsolete SQL for other child elements.
>
> So the best course of action might be to refresh the SQL pane for
> _all_ nodes of the table sub-tree whenever we "officially" know of a
> change on any element in the tree under it - or on any element that
> actually influences the SQL pane of the table. That is what is special
> about the table node: it incorporates information of child objects in
> the SQL pane. Other nodes don't. Except for views. (?)
>
> Or never refresh anything unless the user explicitely requests it. A
> refresh _may_ also be unwelcome, as information may be lost! I have
> used the old information to undo changes that went wrong before ...
>
> As far as I have seen, v1.6.3 behaves the same way.
>
> I AM JUST NOT SURE.
Regards
Erwin