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
