[Bug VW 7.7.1] PostgreSQL encoding set wrong

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The encoding that your database is in shouldn't matter for the client encoding. You should always be able to set it to whatever you want, and the only danger is that if you try to write a character which isn't representable in the database, you get the error for that in a different place.

At 03:58 AM 2010-09-27, Christian Haider wrote:

My PostgreSQL Store has an ASCII encoding, but Store (in 7.7 and 7.7.1) sets the client encoding to unicode.
 
The problem is in the new Glorp based store. Fix is attached.
 
Cheers,
    Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

---

Von: Alan Knight [mailto:[hidden email]]
Gesendet: Montag, 27. September 2010 13:31
An: Christian Haider; VWNC,
Betreff: Re: [vwnc] [Bug VW 7.7.1] PostgreSQL encoding set wrong

The encoding that your database is in shouldn't matter for the client encoding. You should always be able to set it to whatever you want, and the only danger is that if you try to write a character which isn't representable in the database, you get the error for that in a different place.

At 03:58 AM 2010-09-27, Christian Haider wrote:

My PostgreSQL Store has an ASCII encoding, but Store (in 7.7 and 7.7.1) sets the client encoding to unicode.
 
The problem is in the new Glorp based store. Fix is attached.
 
Cheers,
    Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Yes, I'd say that the reason for that is that you've stored the characters with umlauts in a way that the database does not understand. From the Postgresql documentation

The SQL_ASCII setting behaves considerably differently from the other settings. When the server character set is SQL_ASCII, the server interprets byte values 0-127 according to the ASCII standard, while byte values 128-255 are taken as uninterpreted characters. No encoding conversion will be done when the setting is SQL_ASCII. Thus, this setting is not so much a declaration that a specific encoding is in use, as a declaration of ignorance about the encoding. In most cases, if you are working with any non-ASCII data, it is unwise to use the SQL_ASCII setting, because PostgreSQL will be unable to help you by converting or validating non-ASCII characters.st

So if your database has stored the characters as uninterpreted values, and then it tries to put them into UTF-8, it's not going to be able to convert them properly. I would say that using SQL_ASCII as your encoding and then using non-ASCII characters is not a good idea.

At 08:31 AM 2010-09-27, Christian Haider wrote:

maybe you are right in theory...
Unfortunately, I do get an error when reading umlauts (stack trace attached)

---

Von: Alan Knight [[hidden email]]

Gesendet: Montag, 27. September 2010 13:31

An: Christian Haider; VWNC,

Betreff: Re: [vwnc] [Bug VW 7.7.1] PostgreSQL encoding set wrong

The encoding that your database is in shouldn't matter for the client encoding. You should always be able to set it to whatever you want, and the only danger is that if you try to write a character which isn't representable in the database, you get the error for that in a different place.

At 03:58 AM 2010-09-27, Christian Haider wrote:

My PostgreSQL Store has an ASCII encoding, but Store (in 7.7 and 7.7.1) sets the client encoding to unicode.

 

The problem is in the new Glorp based store. Fix is attached.

 

Cheers,

    Christian

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 27 September 2010 15:11, Alan Knight <[hidden email]> wrote:
> So if your database has stored the characters as uninterpreted values, and
> then it tries to put them into UTF-8, it's not going to be able to convert
> them properly. I would say that using SQL_ASCII as your encoding and then
> using non-ASCII characters is not a good idea.

How about:  Creating a new database with a UTF-8 encoding.   Connect
to the old database in the way which preserves the data as desired.
Connect to the new database using a UTF-8 client encoding.  Read from
the old one and write to the new.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc