Re: invalidly encoded strings - Mailing list pgsql-hackers

From Tom Lane
Subject Re: invalidly encoded strings
Date
Msg-id 16292.1189536534@sss.pgh.pa.us
Whole thread Raw
In response to Re: invalidly encoded strings  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: invalidly encoded strings
Re: invalidly encoded strings
Re: invalidly encoded strings
Re: invalidly encoded strings
List 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 by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: Final Thoughts for 8.3 on LWLocking and Scalability
Next
From: Jeff Davis
Date:
Subject: Re: invalidly encoded strings