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.
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.
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.
Cheers,
Andy