Re: UTF8 national character data type support WIP patch and list of open issues.

From: "Robert Haas" <robertmhaas(at)gmail(dot)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