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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
