Skip site navigation (1) Skip section navigation (2)

Re: Patch: add conversion from pg_wchar to multibyte

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: robertmhaas(at)gmail(dot)com
Cc: ishii(at)postgresql(dot)org, aekorotkov(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: add conversion from pg_wchar to multibyte
Date: 2012-07-03 06:17:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> OK.  So, in that case, I suggest that if the leading byte is non-zero,
> we emit 0x9d followed by the three available bytes, instead of first
> testing whether the first byte is >= 0xf0.  That test seems to serve
> no purpose but to confuse the issue.

Probably the code shoud look like this(see below comment):

		else if (lb >= 0xf0 && lb <= 0xfe)
		    if (lb <= 0xf4)
 			  *to++ = 0x9c;
 			  *to++ = 0x9d;
 			*to++ = lb;
 			*to++ = (*from >> 8) & 0xff;
 			*to++ = *from & 0xff;
 			cnt += 4;

> I further suggest that we improve the comments on the mule functions
> for both wchar->mb and mb->wchar to make all this more clear.

I have added comments about mule internal encoding by refreshing my
memory and from old document found on

Please take a look at.  BTW, it seems conversion between multibyte and
wchar can be roundtrip in the leading character is LCPRV2 case:

If the second byte of wchar (out of 4 bytes of wchar. The first byte
is always 0x00) is in range of 0xf0 to 0xf4, then the first byte of
multibyte must be 0x9c.  If the second byte of wchar is in range of
0xf5 to 0xfe, then the first byte of multibyte must be 0x9d.
Tatsuo Ishii
SRA OSS, Inc. Japan

Attachment: pg_wchar.h.patch
Description: text/x-patch (1.7 KB)

In response to


pgsql-hackers by date

Next:From: Jeff DavisDate: 2012-07-03 06:47:58
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree
Previous:From: Pavel StehuleDate: 2012-07-03 06:13:21
Subject: Re: enhanced error fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group