From: "Robert Haas" <robertmh...@gmail.com>
I don't think that you'll be able to
get consensus around that path on this mailing list.
I agree that the fact we have both varchar and text feels like a wart.
Is that right? I don't feel varchar/text case is a wart. I think text was
introduced for a positive reason to ease migration from other DBMSs. The
manual says:
http://www.postgresql.org/docs/current/static/datatype-character.html
"Although the type text is not in the SQL standard, several other SQL
database management systems have it as well."
And isn't EnterpriseDB doing similar things for Oracle compatibility,
although I'm not sure about the details? Could you share your idea why we
won't get consensus?
I understand your feeling. The concern about incompatibility can be
eliminated by thinking the following way. How about this?
- NCHAR can be used with any database encoding.
- At first, NCHAR is exactly the same as CHAR. That is,
"implementation-defined character set" described in the SQL standard is
the
database character set.
- In the future, the character set for NCHAR can be selected at database
creation like Oracle's CREATE DATABAWSE .... NATIONAL CHARACTER SET
AL16UTF16. The default it the database set.
Hmm. So under that design, a database could support up to a total of
two character sets, the one that you get when you say 'foo' and the
other one that you get when you say n'foo'.
I guess we could do that, but it seems a bit limited. If we're going
to go to the trouble of supporting multiple character sets, why not
support an arbitrary number instead of just two?
I agree with you about the arbitrary number. Tatsuo san gave us a good
suggestion. Let's consider how to implement that.
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
