RE: Problem with 7.0.3 dump -> 7.1b4 restore

I just tested a bug I originally fount in 7.1b4 with the new 7.1RC3 and it
still exists. I would consider this a major bug because I know of no work
around.

Basically what happens is that a dump of an existing Unicode database (from
7.03) has a double-byte hyphen character that becomes \255 in the dump. When
the data is imported into the new 7.1 database it seems to correctly appear
(verified via psql) BUT when reading this record via JDBC the data is
truncated at this character.

I communicated briefly with Ishii-san regarding this a while back but I
never followed up. Considering RC3 is now out I thought I should revisit the
issue. It should be easy to test by editing and postgres Unicode database
dump and putting \255 somewhere in a string. I'm not sure if it matters but
the dump was done with "-dn" flags.

Thanks,

--Rainer

> -----Original Message-----
> From: Tatsuo Ishii [mailto:t-ishii(at)sra(dot)co(dot)jp]
> Sent: Wednesday, February 28, 2001 11:02 AM
> To: rmager(at)vgkk(dot)com
> Cc: pgsql-bugs(at)postgresql(dot)org; pgsql-hackers(at)postgresql(dot)org
> Subject: RE: [BUGS] Problem with 7.0.3 dump -> 7.1b4 restore
>
>
> > Attached is a single INSERT that shows the problem. The
> character after the
> > word "Fiber" truncates the text when using JDBC. NOTE, the text
> IS in the
> > database, that is, the dump/restore seems ok, the problem is
> when trying to
> > read the text later. The database is UTF8 and I just tested with beta 5.
> >
> > Oh, BTW, if I try to set (INSERT) this same character via JDBC and then
> > retreive it again then everything is fine.
>
> I have tested your data using psql:
>
> unicode=# create table pr_prop_info(i1 int, i2 int, i3 int, t text);
> CREATE
> unicode=# \encoding LATIN1
> unicode=# \i example.sql
> INSERT 2378114 1
> unicode=# select * from pr_prop_info;
>
> The character after the word "Fiber" looks like "­Optic Cable". So as
> long as the server/client encoding set correctly, it looks ok. I guess
> we have some problems with JDBC driver. Unfortunately I am not a Java
> guru at all. Can anyone look into our JDBC driver regarding this
> problem?
> --
> Tatsuo Ishii