From: "Albe Laurenz" <laurenz.albe@wien.gv.at>
> I looked into the Standard, and it does not have NVARCHAR.
> The type is called NATIONAL CHARACTER VARYING, NATIONAL CHAR VARYING
> or NCHAR VARYING.
OUch, that's just a mistake in my mail. You are correct.
> > I guess that the goal of this patch is to support Oracle syntax.
> But anybody trying to port CREATE TABLE statements from Oracle
> is already exposed to enough incompatibilities that the difference between
> NVARCHAR and NCHAR VARYING will not be the reason to reject PostgreSQL.
> In other words, I doubt that introducing the nonstandard NVARCHAR
> will have more benefits than drawbacks (new reserved word).
Agreed. But I'm in favor of supporting other DBMS's syntax if it doesn't
complicate the spec or implementation too much, because it can help migrate
to PostgreSQL. I understand PostgreSQL has made such efforts like PL/pgSQL
which is similar to PL/SQL, text data type, AS in SELECT statement, etc.
> But I don't think that this requires the first step that your patch
> implements, it is in fact orthogonal.
(It's not "my" patch.)
> Regarding the Standard compliant names of these data types, PostgreSQL
> already supports those. Maybe some documentation would help.
>
> I don't think that there is any need to change NCHAR even if we
> get per-column encoding, it is just syntactic sugar to support
> SQL Feature F421.
Maybe so. I guess the distinct type for NCHAR is for future extension and
user friendliness. As one user, I expect to get "national character"
instead of "char character set xxx" as output of psql \d and pg_dump when I
specified "national character" in DDL. In addition, that makes it easy to
use the pg_dump output for importing data to other DBMSs for some reason.
Regards
MauMau
