Re: Proposal - Support for National Characters functionality

From: "Arulappan, Arul Shaji" <arul(at)fast(dot)au(dot)fujitsu(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal - Support for National Characters functionality
Date: 2013-07-05 06:15:04
Message-ID: 3AFB102B67FAEE48874E0607386DF4210CDE8A12@SYDExchTmp.au.fjanz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Claudio Freire [mailto:klaussfreire(at)gmail(dot)com]
> Sent: Friday, 5 July 2013 3:41 PM
> To: Tatsuo Ishii
> Cc: Arulappan, Arul Shaji; PostgreSQL-Dev
> Subject: Re: [HACKERS] Proposal - Support for National Characters
> functionality
>
> On Fri, Jul 5, 2013 at 2:02 AM, Tatsuo Ishii <ishii(at)postgresql(dot)org>
wrote:
> >> - Support for NATIONAL_CHARACTER_SET GUC variable that will
determine
> >> the encoding that will be used in NCHAR/NVARCHAR columns.
> >
> > You said NCHAR's encoding is UTF-8. Why do you need the GUC if
NCHAR's
> > encoding is fixed to UTF-8?
>
>
> Not only that, but I don't think it can be a GUC. Maybe a compile-time
switch,
> but if it were a GUC, how do you handle an existing database in UTF-8
when the
> setting is switched to UTF-16? Re-encode everything?
> Store the encoding along each value? It's a mess.
>
> Either fix it at UTF-8, or make it a compile-time thing, I'd say.

Agreed, that to begin with we only support UTF-8 encoding for NCHAR
columns. If that is the case, do we still need a compile time option to
turn on/off NCHAR functionality ? ?

Rgds,
Arul Shaji

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2013-07-05 06:50:01 Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Previous Message Arulappan, Arul Shaji 2013-07-05 06:12:33 Re: Proposal - Support for National Characters functionality