public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: MauMau <[email protected]>
Cc: Albe Laurenz <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Arulappan, Arul Shaji <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Tatsuo Ishii <[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 11:46:16 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <7A2BD06B10A24EA4AA5FC5D93A70A754@maumau>
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>
<7A2BD06B10A24EA4AA5FC5D93A70A754@maumau>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
"MauMau" <[email protected]> writes:
> 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.
This argument seems awfully weak. You've been able to say
create table nt (nf national character varying(22));
in Postgres since around 1997, but I don't recall one single bug report
about how that is displayed as just "character varying(22)".
The other big problem with this line of argument is that you're trying
to claim better spec compliance for what is at best a rather narrow
interpretation with really minimal added functionality. (In fact,
until you have a solution for the problem that incoming and outgoing
data must be in the database's primary encoding, you don't actually have
*any* added functionality, just syntactic sugar that does nothing useful.)
Unless you can demonstrate by lawyerly reading of the spec that the spec
requires exactly the behavior this patch implements, you do not have a leg
to stand on here. But you can't demonstrate that, because it doesn't.
I'd be much more impressed by seeing a road map for how we get to a
useful amount of added functionality --- which, to my mind, would be
the ability to support N different encodings in one database, for N>2.
But even if you think N=2 is sufficient, we haven't got a road map, and
commandeering spec-mandated syntax for an inadequate feature doesn't seem
like a good first step. It'll just make our backwards-compatibility
problems even worse when somebody does come up with a real solution.
regards, tom lane
--
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: <[email protected]>
* 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