From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | MauMau *EXTERN* <maumau307(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | "Arulappan, Arul Shaji" <arul(at)fast(dot)au(dot)fujitsu(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Boguk, Maksym" <Maksym(dot)Boguk(at)au(dot)fujitsu(dot)com>, "Heikki Linnakangas" <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UTF8 national character data type support WIP patch and list of open issues. |
Date: | 2013-11-09 20:46:56 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B17C57F0B@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
MauMau wrote:
> Let me repeat myself: I think the biggest and immediate issue is that
> PostgreSQL does not support national character types at least officially.
> "Officially" means the description in the manual. So I don't have strong
> objection against the current (hidden) implementation of nchar types in
> PostgreSQL which are just synonyms, as long as the official support is
> documented. Serious users don't want to depend on hidden features.
I agree with you there.
Actually it is somewhat documented in
http://www.postgresql.org/docs/9.3/static/features-sql-standard.html
as "F421", but that requires that you read the SQL standard.
> However, doesn't the current synonym approach have any problems? Wouldn't
> it produce any trouble in the future? If we treat nchar as char, we lose
> the fact that the user requested nchar. Can we lose the fact so easily and
> produce irreversible result as below?
I don't think that it is a problem.
According to the SQL standard, the user requested a CHAR or VARCHAR with
an encoding of the choice of the DBMS.
PostgreSQL chooses the database encoding.
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.
Again, for serial the behaviour is well documented, so that seconds
your request for more documentation.
Would you like to write a patch for that?
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-11-09 21:58:53 | Fw: [COMMITTERS] pgsql: Fix blatantly broken record_image_cmp() logic for pass-by-value |
Previous Message | Robert Haas | 2013-11-09 19:15:52 | Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block |