Re: invalidly encoded strings

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: invalidly encoded strings
Дата
Msg-id 16292.1189536534@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: invalidly encoded strings  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: invalidly encoded strings  (Jeff Davis <pgsql@j-davis.com>)
Re: invalidly encoded strings  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: invalidly encoded strings  (Andrew Dunstan <andrew@dunslane.net>)
Re: invalidly encoded strings  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote:
>> It might work the way you are expecting if the database uses SQL_ASCII
>> encoding and C locale --- and I'd be fine with allowing convert() only
>> when the database encoding is SQL_ASCII.

> I prefer this option.

I think really the technically cleanest solution would be to make
convert() return bytea instead of text; then we'd not have to put
restrictions on what encoding or locale it's working inside of.
However, it's not clear to me whether there are valid usages that
that would foreclose.  Tatsuo mentioned length() but bytea has that.

What I think we'd need to have a complete solution is

convert(text, name) returns bytea-- convert from DB encoding to arbitrary encoding

convert(bytea, name, name) returns bytea-- convert between any two encodings

convert(bytea, name) returns text-- convert from arbitrary encoding to DB encoding

The second and third would need to do a verify step before
converting, of course.

Comments?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: Final Thoughts for 8.3 on LWLocking and Scalability
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: invalidly encoded strings