Re: Patch: add conversion from pg_wchar to multibyte

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: add conversion from pg_wchar to multibyte
Date: 2012-07-02 20:33:11
Message-ID: CAPpHfdvcTiss1MetkZZth5yzMx=W+bqGuAAdesQ_9rQJmf7vjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 2, 2012 at 8:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
> wrote:
> >> MULE also looks problematic. The code that you've written isn't
> >> symmetric with the opposite conversion, unlike what you did in all
> >> other cases, and I don't understand why. I'm also somewhat baffled by
> >> the reverse conversion: it treats a multi-byte sequence beginning with
> >> a byte for which IS_LCPRV1(x) returns true as invalid if there are
> >> less than 3 bytes available, but it only reads two; similarly, for
> >> IS_LCPRV2(x), it demands 4 bytes but converts only 3.
> >
> > Should we save existing pg_wchar representation for MULE encoding?
> Probably,
> > we can modify it like in 0.1 version of patch in order to make it more
> > transparent.
>
> Changing the encoding would break pg_upgrade, so -1 from me on that.

I didn't realize that we store pg_wchar on disk somewhere. I thought it is
only in-memory representation. Where do we store pg_wchar on disk?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-07-02 20:34:05 Re: Proof of concept: auto updatable views
Previous Message Robert Haas 2012-07-02 20:27:25 Re: Proof of concept: auto updatable views