public inbox for [email protected]
help / color / mirror / Atom feedFrom: MauMau <[email protected]>
To: Albe Laurenz <[email protected]>
To: Robert Haas <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Arulappan, Arul Shaji <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Tatsuo Ishii <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Boguk, Maksym <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
Date: Sun, 10 Nov 2013 17:48:21 +0900
Message-ID: <319421D1A92A44BEAFD8E76AC86FB7AA@maumau> (raw)
In-Reply-To: <A737B7A37273E048B164557ADEF4A58B17C57F0B@ntex2010i.host.magwien.gv.at>
References: <CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com>
<[email protected]>
<CA+TgmoZEy=pt2B5D+nuPAib7KvhNoBgRGYRWnkS4pyrqfcdYHQ@mail.gmail.com>
<[email protected]>
<D0A2FE73E8354EDCBEE56EC79268CA4E@maumau>
<[email protected]>
<7DCFAE8265254605840917B35EEF09F1@maumau>
<CAM-w4HMRCTyemtmKDJPHL72dXH1Gr6q5JrkCNnE63RXLn02Tjw@mail.gmail.com>
<7C2A735AFC3E4088A8F49B677855369C@maumau>
<[email protected]>
<[email protected]>
<CA+TgmoYdsztyG4ML=N69rj2q2XTTjogE38aFtXJxrpyqS9WLjA@mail.gmail.com>
<673E261C589440E3B0D8FDF9A11B1181@maumau>
<A737B7A37273E048B164557ADEF4A58B17C57F0B@ntex2010i.host.magwien.gv.at>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
From: "Albe Laurenz" <[email protected]>
In a way, it is similar to using the "data type" serial. The column will be
displayed as "integer", and the information that it was a serial can
only be inferred from the DEFAULT value.
It seems that this is working fine and does not cause many problems,
so I don't see why things should be different here.
Yes, I agree with you in that serial being a synonym is almost no problem.
But that's because serial is not an SQL-standard data type but a type unique
to PostgreSQL.
On the other hand, nchar is an established data type in the SQL standard. I
think most people will expect to get "nchar" as output from psql \d and
pg_dump as they specified in DDL. If they get "char" as output for "nchar"
columns from pg_dump, wouldn't they get in trouble if they want to import
schema/data from PostgreSQL to other database products? The documentation
for pg_dump says that pg_dump pays attention to easing migrating to other
DBMSs. I like this idea and want to respect this.
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.
...
--use-set-session-authorization
Output SQL-standard SET SESSION AUTHORIZATION commands instead of ALTER
OWNER commands to determine object ownership. This makes the dump more
standards-compatible, ...
--------------------------------------------------
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], [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: <319421D1A92A44BEAFD8E76AC86FB7AA@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