Hi everyone,
I will try answer on all questions related to proposed National
Characters support.
2)Provide support for the new GUC nchar_collation to provide the
database with information about the default collation that needs to
be
used for the new data types.
A GUC seems like completely
Boguk, Maksym escribió:
I think I give a wrong description there... it will be not GUC but
GUC-type value which will be initialized during CREATE DATABASE and will
be read only after, very similar to the lc_collate.
So I think name national_lc_collate will be better.
Function of this value
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Also, as far as I understand what we want to control here is the
encoding that the strings are in (the mapping of bytes to characters),
not the collation (the way a set of strings are ordered). So it doesn't
make sense to set the NATIONAL
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Boguk, Maksym escribió:
I think I give a wrong description there... it will be not GUC but
GUC-type value which will be initialized during CREATE DATABASE and
will be read only after, very similar to the lc_collate.
So I think
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Also, as far as I understand what we want to control here is the
encoding that the strings are in (the mapping of bytes to
characters),
not the collation (the way a set of strings are ordered). So
-Original Message-
From: Tatsuo Ishii [mailto:is...@postgresql.org]
Also I don't understand why you need UTF-16 support as a database
encoding
because UTF-8 and UTF-16 are logically equivalent, they are just
different
represention (encoding) of Unicode. That means if we already
Arulappan, Arul Shaji a...@fast.au.fujitsu.com writes:
Given below is a design draft for this functionality:
Core new functionality (new code):
1)Create and register independent NCHAR/NVARCHAR/NTEXT data types.
2)Provide support for the new GUC nchar_collation to provide the
database with
On Mon, Jul 15, 2013 at 05:11:40PM +0900, Tatsuo Ishii wrote:
Does support for alternative multi-byte encodings have something to do
with the Han unification controversy? I don't know terribly much about
this, so apologies if that's just wrong.
There's a famous problem regarding
On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not *everything*
On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I
didn't see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue
On Mon, Jul 15, 2013 at 8:58 AM, Tatsuo Ishii is...@postgresql.org wrote:
Also I don't understand why you need UTF-16 support as a database
encoding because UTF-8 and UTF-16 are logically equivalent, they are
just different represention (encoding) of Unicode. That means if we
already support
On 7/15/13 1:26 AM, Arulappan, Arul Shaji wrote:
Yes, the idea is that users will be able to declare columns of type
NCHAR or NVARCHAR which will use the pre-determined encoding type. If we
say that NCHAR is UTF-8 then the NCHAR column will be of UTF-8 encoding
irrespective of the database
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue with Asian
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I
didn't see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue
Ishii san,
Thank you for your positive and early response.
-Original Message-
From: Tatsuo Ishii [mailto:is...@postgresql.org]
Sent: Friday, 5 July 2013 3:02 PM
To: Arulappan, Arul Shaji
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal - Support for National
-Original Message-
From: Claudio Freire [mailto:klaussfre...@gmail.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
On 07/05/2013 02:12 AM, Arulappan, Arul Shaji wrote:
- Support for UTF16 column encoding and representing NCHAR and
NVARCHAR columns in UTF16 encoding in all databases.
Why do yo need UTF-16 as the database encoding? UTF-8 is already
supported,
and any UTF-16 character can be represented in
On 7/4/13 10:11 PM, Arulappan, Arul Shaji wrote:
The main aim at the moment is to get some feedback on the above to know
if this feature is something that would benefit PostgreSQL in general,
and if users maintaining DBs in non-English speaking regions will find
this beneficial.
For European
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Dne 5.7.2013 20:28 Peter Eisentraut pete...@gmx.net napsal(a):
On 7/4/13 10:11 PM, Arulappan, Arul Shaji wrote:
The main aim at the moment is to get some feedback on the above
This is a proposal to implement functionalities for the handling of
National Characters.
[Introduction]
The aim of this proposal is to eventually have a way to represent
'National Characters' in a uniform way, even in non-UTF8 encoded
databases. Many of our customers in the Asian region who are
Arul Shaji,
NCHAR support is on our TODO list for some time and I would like to
welcome efforts trying to implement it. However I have a few
questions:
This is a proposal to implement functionalities for the handling of
National Characters.
[Introduction]
The aim of this proposal is to
On Fri, Jul 5, 2013 at 2:02 AM, Tatsuo Ishii is...@postgresql.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
23 matches
Mail list logo
