public inbox for [email protected]
help / color / mirror / Atom feedFrom: MauMau <[email protected]>
To: Robert Haas <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Boguk, Maksym <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: [email protected]
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
Date: Tue, 24 Sep 2013 07:41:51 +0900
Message-ID: <08BC1DEE597E44B792B411CAF75BAE16@maumau> (raw)
In-Reply-To: <CA+Tgmoa1jpOR1zC=Vrcr_+7DZbXDsORz+CeOxMX1qbcFfpy_cg@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<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>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
From: "Robert Haas" <[email protected]>
> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (62+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
In-Reply-To: <08BC1DEE597E44B792B411CAF75BAE16@maumau>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox