Re: UTF8 national character data type support WIP patch and list of open issues. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: UTF8 national character data type support WIP patch and list of open issues.
Date
Msg-id CA+Tgmoa1jpOR1zC=Vrcr_+7DZbXDsORz+CeOxMX1qbcFfpy_cg@mail.gmail.com
Whole thread Raw
In response to Re: UTF8 national character data type support WIP patch and list of open issues.  ("MauMau" <maumau307@gmail.com>)
Responses Re: UTF8 national character data type support WIP patch and list of open issues.
List pgsql-hackers
On Fri, Sep 20, 2013 at 8:32 PM, MauMau <maumau307@gmail.com> wrote:
>> 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?

Sure, it's EnterpriseDB's policy to add features that facilitate
migrations from other databases - particularly Oracle - to our
product, Advanced Server, even if those features don't otherwise add
any value.  However, the community is usually reluctant to add such
features to PostgreSQL.  Also, at least up until now, the existing
aliasing of nchar and nchar varying to other data types has been
adequate for the needs of our customers, and we've handled a bunch of
other type-name incompatibilities with similar tricks.  What you are
proposing goes off in a different direction from both PostgreSQL and
Advanced Server, and that's why I'm skeptical.  If you were proposing
something that we were doing in Advanced Server with great success, it
would be a bit disingenuous of me to argue against doing the same
thing in PostgreSQL, but that's not the case.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: output/security_label.source referring to abs_builddir instead of libdir
Next
From: Andres Freund
Date:
Subject: Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline