> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>
> Alvaro Herrera 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
> 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
Alvaro Herrera 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 CHARACTER option using the
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 va
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 compl
"Arulappan, Arul Shaji" 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 information about t
> -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 alre
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 co
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 Mon, Jul 15, 2013 at 8:58 AM, Tatsuo Ishii 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 UTF-8 (I'm sure we
>> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
> 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 l
> On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas wrote:
>> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
>> 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;
On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas wrote:
> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule 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 th
>
> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
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 langua
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule 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 languages.
If we cho
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" 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 to know
> >
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 Europe
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 U
> -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
>
&g
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 - Su
On Fri, Jul 5, 2013 at 2:02 AM, Tatsuo Ishii 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 o
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 i
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
23 matches
Mail list logo
