Re: invalidly encoded strings

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: invalidly encoded strings
Дата
Msg-id 46EFBFA7.7090905@dunslane.net
обсуждение исходный текст
Ответ на Re: invalidly encoded strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: invalidly encoded strings  (Hannu Krosing <hannu@skype.net>)
Re: invalidly encoded strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: invalidly encoded strings  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> Tom Lane wrote:
>>     
>>> 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.
>>>       

>> I'm wondering if we should give them disambiguating names, rather than 
>> call them all convert.
>>     
>
> No.  We have a function overloading system, we should use it.
>
>             
>   
In general I agree with you.

What's bothering me here though is that in the two argument forms, if 
the first argument is text the second argument is the destination 
encoding, but if the first argument is a bytea the second argument is 
the source encoding. That strikes me as likely to be quite confusing, 
and we might alleviate that with something like:
 text convert_from(bytea, name) bytea convert_to(text, name)

But if I'm the only one bothered by it I won't worry.

cheers

andrew


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Open issues for HOT patch
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: invalidly encoded strings