From: "Robert Haas" <robertmhaas@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