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