Re: Results from testing RC2, rev: 5607:5627M

From: Dave Page <dpage(at)postgresql(dot)org>
To: Erwin Brandstetter <brandstetter(at)falter(dot)at>
Cc: pgadmin-support(at)postgresql(dot)org
Subject: Re: Results from testing RC2, rev: 5607:5627M
Date: 2006-11-14 09:44:30
Message-ID: 45598FFE.20508@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support

Erwin Brandstetter wrote:

> - Starting new lines by inserting data is now less confusing, the new
> dialogue prevents data loss. And the option to cancel the operation is a
> major improvement. That's the one I will be using 99% of the time.
> The current way of handling cursor and selection will remain prone to
> errors and cornercases, though.

Maybe - but I think they really are corner cases for the most part.
You're pretty much the only complainant in 5 years or so! (not that I'm
saying they shouldn't be fixed you understand).

>
> - The undead "undo" issue:
> The save dialogue pops up, even if there is no data to save, even if I
> did not enter edit mode in the row of the cursor at all, or if I set the
> cursor on the "new" row. This isn't dangerous, but confusing.
> If I answer yes to the uncalled-for save dialogue, then the rest of the
> operation seems to be aborted (nothing happens).

Yeah, think I've got this case nailed. Will send you an exe for testing.

>
> - While experimenting with pasting, I pasted the dummy text 'asdfg' to
> an integer column and saved - which produced an error as expected. The
> nature of the error was a bit of a surprise though:
>
> An error has occurred:
> FEHLER: Spalte >>asdfg<< existiert nicht.
>
> Meaning: "Error: Column >>asdfg<< does not exist."
> Somehow data is being mistaken for a column name. This could possibly
> lead to grave errors. (Or is it the German translation wrong?)

Hmm. This only happens because the underlying text control handles it's
own paste operations - when you type into a numeric field, we filter out
invalid characters (ie. alpha), but when pasting that doesn't happen.
That will take some real effort to resolve properly.

For now, I've just made sure that numeric data gets quoted to remove the
column/funtion ambiguity with unquoted text. That will at least ensure
that the user gets a sensible error message from the server.

Regards, Dave.

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Mike Knell 2006-11-14 13:41:43 CONN ERROR: func=original_CC_connect, desc='"', errnum=210, errmsg=''"
Previous Message Erwin Brandstetter 2006-11-13 23:43:38 Re: Results from testing RC2, rev: 5607:5627M