From: "Robert Haas" <robertmh...@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

Reply via email to