public inbox for [email protected]
help / color / mirror / Atom feedFrom: MauMau <[email protected]>
To: Albe Laurenz <[email protected]>
To: Arulappan, Arul Shaji *EXTERN* <[email protected]>
To: Greg Stark <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Tatsuo Ishii <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Boguk, Maksym <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
Date: Tue, 5 Nov 2013 21:32:49 +0900
Message-ID: <6C7E3D3C38CE4E0BAF20269F7E2DBA21@maumau> (raw)
In-Reply-To: <A737B7A37273E048B164557ADEF4A58B17C563E8@ntex2010i.host.magwien.gv.at>
References: <CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com>
<[email protected]>
<CA+TgmoZEy=pt2B5D+nuPAib7KvhNoBgRGYRWnkS4pyrqfcdYHQ@mail.gmail.com>
<[email protected]>
<D0A2FE73E8354EDCBEE56EC79268CA4E@maumau>
<[email protected]>
<7DCFAE8265254605840917B35EEF09F1@maumau>
<CAM-w4HMRCTyemtmKDJPHL72dXH1Gr6q5JrkCNnE63RXLn02Tjw@mail.gmail.com>
<7C2A735AFC3E4088A8F49B677855369C@maumau>
<[email protected]>
<A737B7A37273E048B164557ADEF4A58B17C563E8@ntex2010i.host.magwien.gv.at>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
From: "Albe Laurenz" <[email protected]>
> If I understood the discussion correctly the use case is that
> there are advantages to having a database encoding different
> from UTF-8, but you'd still want sume UTF-8 columns.
>
> Wouldn't it be a better design to allow specifying the encoding
> per column? That would give you more flexibility.
Yes, you are right. In the previous discussion:
- That would be nice if available, but it is hard to implement multiple
encodings in one database.
- Some people (I'm not sure many or few) are NCHAR/NVARCHAR in other DBMSs.
To invite them to PostgreSQL, it's important to support national character
feature syntactically and document it in the manual. This is the first
step.
- As the second step, we can implement multiple encodings in one database.
According to the SQL standard, "NCHAR(n)" is equivalent to "CHAR(n)
CHARACTER SET cs", where cs is an implementation-defined character set.
Regards
MauMau
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (62+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
In-Reply-To: <6C7E3D3C38CE4E0BAF20269F7E2DBA21@maumau>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox