Hannu Krosing wrote:
> Ühel kenal päeval, T, 2007-09-18 kell 08:08, kirjutas Andrew Dunstan:
>
>> 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)
>>
>
> how is this fundamentally different from encode/decode functions we have
> now ?
>
>
>
They are in effect reversed. encode() applies the named encoding to a
bytea. convert_from() above unapplies the named encoding (i.e. converts
the bytea to text in the database encoding).
cheers
andrew