Re: Patch: add conversion from pg_wchar to multibyte - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Patch: add conversion from pg_wchar to multibyte
Date
Msg-id CAPpHfdv8_fa6FCCe_sHndDaAcdA6R28tO-A7PQJSC2joizHmpA@mail.gmail.com
Whole thread Raw
In response to Patch: add conversion from pg_wchar to multibyte  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Patch: add conversion from pg_wchar to multibyte
List pgsql-hackers
Hello, Ishii-san!

We've talked on PGCon that I've questions about mule to wchar conversion. My questions about pg_mule2wchar_with_len function are following. In these parts of code:

else if (IS_LCPRV1(*from) && len >= 3)
{
    from++;
    *to = *from++ << 16;
    *to |= *from++;
    len -= 3;
}

and

else if (IS_LCPRV2(*from) && len >= 4)
{
    from++;
    *to = *from++ << 16;
    *to |= *from++ << 8;
    *to |= *from++;
    len -= 4;
}

we skip first character of original string. Are we able to restore it back from pg_wchar?
Also in this part of code we're shifting first byte by 16 bits:

if (IS_LC1(*from) && len >= 2)
{
    *to = *from++ << 16;
    *to |= *from++;
    len -= 2;
}
else if (IS_LCPRV1(*from) && len >= 3)
{
    from++;
    *to = *from++ << 16;
    *to |= *from++;
    len -= 3;
}

Why don't we shift it by 8 bits?
You can see my patch in this thread where I propose purely mechanical changes in this function which make inverse conversion possible.

------
With best regards,
Alexander Korotkov.

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Bug in new buffering GiST build code
Next
From: Ants Aasma
Date:
Subject: Re: Why is indexonlyscan so darned slow?