Re: UTF8 conversion differences from v8.1.3 to v8.1.4
От | Eric Faulhaber |
---|---|
Тема | Re: UTF8 conversion differences from v8.1.3 to v8.1.4 |
Дата | |
Msg-id | 44BFAA5A.9020103@goldencode.com обсуждение исходный текст |
Ответ на | Re: UTF8 conversion differences from v8.1.3 to v8.1.4 (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: UTF8 conversion differences from v8.1.3 to v8.1.4
|
Список | pgsql-general |
Martijn van Oosterhout wrote: > On Wed, Jul 19, 2006 at 06:06:08PM -0400, Eric Faulhaber wrote: >> Martijn van Oosterhout wrote: >>> On Wed, Jul 19, 2006 at 05:24:53PM -0400, Eric Faulhaber wrote: >>>> OK, but now that this "feature" has been removed in 8.1.4, how is this >>>> supposed to be handled, given that we don't control what string data >>>> we're handed? How does psql deal with it? >>> Well, bytea handles null like it always has. There must be a way to you >>> to store strings into bytea columns... But I only have a vague >>> understanding of why bytea won't work for you... >> Collation, for one. Our runtime is extremely sensitive to the order in >> which records are read, to the point where I've created a custom locale >> just for the PostgreSQL cluster. >> >> Then there's case sensitivity, being able to use string functions in >> SQL, etc., etc. Bottom line, these are valid strings, so we need to >> treat them as such. > > Well, there's a really nasty workaround: create a cast from bytea to > text which doesn't change the value. This will get your data into the > database without any encoding checks at all. Ofcourse, you're then > responsible for any problems caused down the line... > > Have a nice day, Not sure I understand... at what point is the cast performed and what type is actually stored in the database: text or bytea? Thanks, Eric
В списке pgsql-general по дате отправления: