Re: pgAdmin III Query Tool bug

Hi Dave,

Ignore issue 2 then if it is a known issue.

With issue 1, I have isolated two offending characters that cause the
problem: "ī" (c4ab) and "ḥ" (e1b8a5). The inclusion of either one of
them will lead to an empty file being stored. I'm using the characters
for phonetic Arabic transliterations, but the characters are probably
used in other real world contexts as well. I have included a file as an
attachment with an example that causes the file to be saved as a 0 byte
file from the Query tool. I have also included the actual Arabic
characters as well, which also if present will cause the same behaviour.
Essentially, it does not appear that the Query tool supports true UTF-8
or unicode characters.

I doubt that the inclusion of these characters with version 1.8.0 would
have ever worked either, but I am now up to 1.8.1 and know that with
this version the inclusion of either of these characters will always
cause the problem. So ignore my probably erroneous observation that the
previous version only started being problematic after being open for a
period of time.

Regards,

Andy

Dave Page wrote:
> 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>
>