Message-ID: <08BC1DEE597E44B792B411CAF75BAE16@maumau>
From: "MauMau" <maumau307@gmail.com>
To: "Robert Haas" <robertmhaas@gmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>,
 "Boguk, Maksym" <maksymb@fast.au.fujitsu.com>,
 "Heikki Linnakangas" <hlinnakangas@vmware.com>,
 <pgsql-hackers@postgresql.org>
References: 
 <A756FAD7EDC2E24F8CAB7E2F3B5375E918E2D5B8@FALEX03.au.fjanz.com><522594E8.2050106@vmware.com><A756FAD7EDC2E24F8CAB7E2F3B5375E918F332A6@FALEX03.au.fjanz.com><904.1378304922@sss.pgh.pa.us><B1A7485194DE4FDAB8FA781AFB570079@maumau><CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com><B00EACB87A2441069B4EE4DEA6D9282A@maumau><CA+TgmoaT-h5C25LXd1DgfyiW2t9K92eVdVcJHC_1We0JpJFqgg@mail.gmail.com><37B76474BB3149FD841373E12E355851@maumau><CA+TgmoZENYsQ5BwsjKz+SU8e1+JjtHNLqz4q9=FYn7n_dHBw_w@mail.gmail.com><A33C037F0BB04126AD5F7CEE69B8F619@maumau>
 <CA+Tgmoa1jpOR1zC=Vrcr_+7DZbXDsORz+CeOxMX1qbcFfpy_cg@mail.gmail.com>
In-Reply-To: 
 <CA+Tgmoa1jpOR1zC=Vrcr_+7DZbXDsORz+CeOxMX1qbcFfpy_cg@mail.gmail.com>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Tue, 24 Sep 2013 07:41:51 +0900
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
 reply-type=original
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

From: "Robert Haas" <robertmhaas@gmail.com>
> Sure, it's EnterpriseDB's policy to add features that facilitate
> migrations from other databases - particularly Oracle - to our
> product, Advanced Server, even if those features don't otherwise add
> any value.  However, the community is usually reluctant to add such
> features to PostgreSQL.  Also, at least up until now, the existing
> aliasing of nchar and nchar varying to other data types has been
> adequate for the needs of our customers, and we've handled a bunch of
> other type-name incompatibilities with similar tricks.  What you are
> proposing goes off in a different direction from both PostgreSQL and
> Advanced Server, and that's why I'm skeptical.  If you were proposing
> something that we were doing in Advanced Server with great success, it
> would be a bit disingenuous of me to argue against doing the same
> thing in PostgreSQL, but that's not the case.

Sorry, I didn't mean to imitate EnterpriseDB.  My intent is to just increase 
the popularity of PostgreSQL (or prevent the drop in popularity?).  NCHAR is 
so basic that we can/should accept proper support.

Aliasing would be nice to some extent, if its offical support would be 
documented in PG manual.  However, just aliasing loses NCHAR type 
information through pg_dump.  This is contrary to the benefit of pg_dump --  
allow migration from PG to other DBMSs, possibly for performance comparison:

http://www.postgresql.org/docs/current/static/app-pgdump.html

"Script files can be used to reconstruct the database even on other machines 
and other architectures; with some modifications, even on other SQL database 
products."

In addition, distinct types for NCHAR/NVARCHAR allow future extension such 
as different encoding for NCHAR and UTF-16.


Regards
MauMau


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers