Testing 1.7: issues in edit grid & query window - Mailing list pgadmin-hackers

Hi developers! Hi Dave!

Still testing  pgAdmin III 1.7.0, rev 6292:6293. Client Win XP, hosts:
Debian Sarge / PG 8.1.8 (and occasionally Debian Etch / PG 8.2.3)


Edit grid
=========

The edit grid suppresses NULL values ON INSERTs (UPDATEs are not
affected). Example. Say we have a table:

    CREATE TABLE mankind
    (
      man_id integer primary key,
      people_id integer,
      king boolean DEFAULT false
    );

When I enter "24 for "man_id", "2" for "people_id" and do not enter
anything for "king" in the edit grid this statement is sent to the database:
    INSERT INTO mankind(man_id, people_id) VALUES ('24'::integer,
'2'::integer)
Which is correct.

When I do the same, but explicitly select NULL in the control for the
boolean field king, though, the statement will still be the same:
    INSERT INTO mankind(man_id, people_id) VALUES ('24'::integer,
'2'::integer)
Which is wrong.
 The field "king" will be assigned the DEFAULT VALUE false.

 It should be
    INSERT INTO mankind(man_id, people_id, king) VALUES ('24'::integer,
'2'::integer, 'NULL'::boolean)
So the field is actually set to NULL.

In contrast to that, UPDATEs work as expected:
    UPDATE mankind SET king=NULL::boolean WHERE man_id = '24'::integer


While being at it, I noticed a somewhat inconsistent formatting:
    INSERT INTO mankind(man_id, people_id, king) VALUES ('24'::integer,
'2'::integer, TRUE::boolean)
These forms would be consistent:
    INSERT INTO mankind(man_id, people_id, king) VALUES ('24'::integer,
'2'::integer, 'TRUE'::boolean)
    INSERT INTO mankind(man_id, people_id, king) VALUES (24::integer,
2::integer, TRUE::boolean)
    INSERT INTO mankind(man_id, people_id, king) VALUES (24, 2, TRUE)
You get the point - why treat boolean differently?
All of the above is present in 1.6.3.


Query Window
============

If I have a couple of windows open and get an error message in one of
them and do not click it away (because I want to keep the text while
checking on the issue), then the following weirdness occurs:
Pressing <Ctrl><c> does not copy selected text in the query window any
more, but copies the text of the open error message of the other window
(somewhere in the background).
Copying via selecting "Copy" from the context menu will copy the
selected text as expected.
This is also present in 1.6.3.

-----

If I select text and type something else the selected text will be
replaced. This works as it should.
When I press <Enter>, however, the select text is NOT replaced. Instead
the line-break is inserted at the end of the selected text. Might share
roots with the issue below.
This is NOT present in 1.6.3, where it works as expected.

-----

You have a new auto-indentation in 1.7, which works fine most of the
time. However, sometimes it fails with existing lines of text. Try the
following test case:
Both lines are indented the same (three spaces in my example):
---
   text1
   text2
---

Now, place the cursor right before the first printable character and
press <Enter>. It works as expected, mostly:
---
   text1

   text2
---
Note, however, that useless whitespace remains on the empty line in between.

If you place the cursor at the beginning of the line and press <Enter>,
the leading whitespace is doubled (which is not as expected)
---
   text1

      text2
---
At least, the whitespace in between is gone.
Obviously, this is not present in 1.6.3.

That's all, folks! For now. :)


Regards
Erwin