Re: pgAdmin III Query Tool bug

On 07/01/2008, Andrew <archa(at)pacific(dot)net(dot)au> wrote:
> OS: WinXP SP2
> PC: Pentium D 3 GHz, 2 GB RAM
> pgAdmin ver: 1.8.0, 1.8.1
> postgresql ver: 8.2.5-1
>
> I haven't been able to find these issues on the Internet or on the
> pgAdmin web site, so hopefully they are not duplicates of existing.
>
> Issue 1:
>
> Working on a ~ 1 MB *.sql file from the Query Tool - a schema file,
> inclusive of reference data of a database that I'm attempting to migrate
> from MySQL. When I save from the pgAdmin Query Tool, it saves a 0 byte
> UTF-8 encoded file (presumably there is still some data saved for
> Windows to realise that it is not an ANSI file). Yet it opens the 1 MB
> file fine when restored from svn, or when the data is copied from the
> Query Tool and saved through notepad as a UTF-8 file and other than
> missing datatypes such as uuid's that I still need to address, the
> parser is happy with the syntax. The save silently changes the dirty
> status of the file to clean - as indicated by removing the asterix from
> the file name in the application title bar, without providing an
> indication of a failed save (which is the worst part).
>
> Initially, it only seemed to occur after the application had been
> running for a few hours, with saves in the initial editing time saving
> fine, then after being running for awhile (several hours), subsequent
> saves began to save as 0 kb files. At least this seemed to be the
> behaviour with pgAdmin 1.8.0. Since upgrading to pgAdmin 1.8.1, every
> save of the file results in a 0 kb output, regardless of how long the
> application has been running.

I cannot reproduce this here. Can you send me a sample file for which
it always fails please?

> Potentially the content in the file itself has become corrupted
> somewhere along the line leading to the bad saves, but at the very
> least, I would expect the Query Tool to flag in some manner that the
> file could not be saved, not silently create a 0 kb file and indicate a
> successful save.

Agreed.

> Issue 2:
>
> This is trivial, but when a syntax error is detected in a large file
> (20,000+ lines), the parser gets the line number correct of the syntax
> error, but the further down the file the syntax error is, the greater
> the distance the error marker is off the target, with the error marker
> pulling up short of the faulty line.

This sounds like a known bug in wxWidgets. The Styled Text Control
doesn't play well with multi-byte characters and can return position
values in bytes when they should be in characters.

Regards, Dave.