Re: UTF8 national character data type support WIP patch and list of open issues.

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

In response to

Responses

Browse pgsql-hackers by date

  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