dpage@postgresql.org wrote:
> OK, I figured out how to hierarchically retain the expanded/collapsed
> state of the child nodes during refresh - turned out to be *much* easier
> that I thought it would be.
>
> I've updated the .exe again - please let me know what you think.
>
Very good! But some things are not right ..
Testing Beta 3.5(Aug 29 2007, rev: 6584:6588M) on Win XP. Client Win XP,
host: Debian Etch / PG 8.2.4 and Debian Sarge / PG 8.1.8.
Everything concerns the table subtree.
- Generally: either the focus jumps to the table node OR the table node
is not updated. We want the focus to stay with (or go back to) the object we are
working on, while (after) the table node is updated.
Objects that do not update the table node: - primary key constraint - check constraint
Objects that update the table node, but lose the focus: - foreign key constraint - unique constraint - table
column
- Trying to add a comment to UNIQUE CONSTRAINT fails altogether.
- ALL comments on constraints or indexes are missing in the reverse
engineered SQL for the table. To be precise, they are present as
comments, but the SQL statements to recreate them are missing: COMMENT ON CONSTRAINT test_pkey ON loc_status IS 'My
commenton
this field...';
- When creating a new FOREIGN KEY CONSTRAINT per dialog (I do these
things with SQL normally) "New Object -> New Foreign Key .." I cannot
enter a comment. It won't let me write in the field. I can add comments to existing constraint of the kind, though.
Thefield "Tablespace" seems to do nothing at all. Choosing a
different tablespace does not activate the OK button. IF I activate the
OK button with other changes and save, the tablespace setting is ignored. - SQL pane of the table is NOT updated.
Onlyafter a manual refresh
does the new foreign key show up.
- There is a checkbox "Auto FK index" among the properties for FOREIGN
KEY CONSTRAINTs. But I cannot find an explanation what it does anywhere. I guessed it
creates an index on the referencing field. When I check the box and save, nothing seems to happen. The
additional index is still created as expected, but the index collection
is not refreshed. Only after manual refresh does the new index show up.
- Trying to update a TRIGGER fails altogether. It tries to send SQL in
the form: CREATE OR REPLACE TRIGGER mytrigger AFTER INSERT ...
But there is no "CREATE OR REPLACE" for triggers.
http://www.postgresql.org/docs/current/static/sql-createtrigger.html
Regards
Erwin