"John Hansen" <[EMAIL PROTECTED]> writes:
> Errm.. UTF-16/32
Ah, I thought that was what you meant.
Right now we have a *ton* of problems with supporting encodings that
need embedded zero bytes, because there are APIs all over the place
that use zero-terminated strings. I don't foresee that it w
Errm.. UTF-16/32
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of John Hansen
> Sent: Wednesday, May 04, 2005 1:22 PM
> To: Tom Lane; Tatsuo Ishii
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] A proper fix
"John Hansen" <[EMAIL PROTECTED]> writes:
>> Are there any encodings we care about that require embedded zero
> bytes?
> UTF-8 does!
Surely not. Were you thinking of UTF-16 or UCS-2 or whatever it's
called?
regards, tom lane
---(end of broadcast)
On 2005-05-04, "John Hansen" <[EMAIL PROTECTED]> wrote:
>> Are there any encodings we care about that require embedded zero
>> bytes?
>
> UTF-8 does!
nonsense
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast)
> Are there any encodings we care about that require embedded zero
bytes?
UTF-8 does!
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Going forward, though, I really think we need to revisit the API
>> for conversion functions. It seems a bit silly to have the
>> infrastructure to let ordinary users create conversions if they
>> can't create the functions needed to support them.
> Why
> I tried disabling public EXECUTE access on the built-in conversion
> functions, as we recommended yesterday, and found that it has one
> small problem: the conversion regression test fails. The test is
> expecting that unprivileged users can create conversions, but since
> CREATE CONVERSION requ
