public inbox for [email protected]  

help / color / mirror / Atom feed

From: MauMau <[email protected]>
To: Valentine Gogichashvili <[email protected]>
To: [email protected]
Cc: Robert Haas <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Boguk, Maksym <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
Date: Sat, 21 Sep 2013 09:07:13 +0900
Message-ID: <F98A2B6D87404A7D8134F6C50BAACAD5@maumau> (raw)
In-Reply-To: <CAP93muULVtyd-HQd=h2VOWzaPUrf2Z9efqXDJvmV0Xx3Auj16Q@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<B1A7485194DE4FDAB8FA781AFB570079@maumau>
	<CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com>
	<B00EACB87A2441069B4EE4DEA6D9282A@maumau>
	<CA+TgmoaT-h5C25LXd1DgfyiW2t9K92eVdVcJHC_1We0JpJFqgg@mail.gmail.com>
	<37B76474BB3149FD841373E12E355851@maumau>
	<CAP93muULVtyd-HQd=h2VOWzaPUrf2Z9efqXDJvmV0Xx3Auj16Q@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

From: "Valentine Gogichashvili" <[email protected]>
> the whole NCHAR appeared as hack for the systems, that did not have it 
> from
> the beginning. It would not be needed, if all the text would be magically
> stored in UNICODE or UTF from the beginning and idea of character would be
> the same as an idea of a rune and not a byte.

I guess so, too.


> PostgreSQL has a very powerful possibilities for storing any kind of
> encoding. So maybe it makes sense to add the ENCODING as another column
> property, the same way a COLLATION was added?

Some other people in this community suggested that.  ANd the SQL standard 
suggests the same -- specifying a character encoding for each column: 
CHAR(n) CHARASET SET ch.


> Text operations should work automatically, as in memory all strings will 
> be
> converted to the database encoding.
>
> This approach will also open a possibility to implement custom ENCODINGs
> for the column data storage, like snappy compression or even BSON, gobs or
> protbufs for much more compact type storage.

Thanks for your idea that sounds interesting, although I don't understand 
that well.

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]
  Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
  In-Reply-To: <F98A2B6D87404A7D8134F6C50BAACAD5@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