2008/8/11 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> Pavel Stehule wrote:
>>
>> Hello,
>>
>> combination functions to_ascii and convert_to is broken now. Problem
>> is in convert_to function. It doesn't support 8bit output encoding.
>>
>> Current workaround:
>>
>> CREATE FUNCTION to_ascii(bytea, name)
>> RETURNS text AS 'to_ascii_encname' LANGUAGE internal;
>>
>> SELECT to_ascii(convert_to('Příliš žlutý kůň', 'latin2'),'latin2');
>>
>> I don't expect column collate for 8.4, so we need to have workable
>> to_ascii function.
>>
>> I propose function to_ascii(text, name) that internally convert text
>> from utf8 encoding when it's necessary.cheers
>>
>>
>>
>
> convert_to is not broken. It returns a bytea, and it is up to you to
> de-escape it if you get the text representation.One note - convert_to is correct. But we have to use to_ascii without decode functions. It has same behave - convert from bytea to text. Text in "incorrect" encoding is dafacto bytea. So correct to_ascii function prototypes are: to_ascii(text) to_ascii(bytea, integer); to_ascii(bytea, name); Regards Pavel Stehule > > We are surely not going to go back to a situation where we have functions > returning text in any encoding other than the database encoding. That > becomes a vehicle for storing wrongly encoded data in the database, and we > have just gone through the exercise of plugging those holes. I privately > predicted when we did this work that it might motivate people who had been > abusing convert_to to get proper support for multiple encodings done. That > is the right way to go, not re-opening holes we have just very deliberately > plugged. > > > > cheers > > andrew > -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
