Re: UTF8 national character data type support WIP patch and list of open issues.
От | Albe Laurenz |
---|---|
Тема | Re: UTF8 national character data type support WIP patch and list of open issues. |
Дата | |
Msg-id | A737B7A37273E048B164557ADEF4A58B17C563E8@ntex2010i.host.magwien.gv.at обсуждение исходный текст |
Ответ на | Re: UTF8 national character data type support WIP patch and list of open issues. ("Arulappan, Arul Shaji" <arul@fast.au.fujitsu.com>) |
Ответы |
Re: UTF8 national character data type support WIP patch and list of open issues.
|
Список | pgsql-hackers |
Arul Shaji Arulappan wrote: > Attached is a patch that implements the first set of changes discussed > in this thread originally. They are: > > (i) Implements NCHAR/NVARCHAR as distinct data types, not as synonyms so > that: > - psql \d can display the user-specified data types. > - pg_dump/pg_dumpall can output NCHAR/NVARCHAR columns as-is, > not as CHAR/VARCHAR. > - Groundwork to implement additional features for NCHAR/NVARCHAR > in the future (For eg: separate encoding for nchar columns). > (ii) Support for NCHAR/NVARCHAR in ECPG > (iii) Documentation changes to reflect the new data type If I understood the discussion correctly the use case is that there are advantages to having a database encoding different from UTF-8, but you'd still want sume UTF-8 columns. Wouldn't it be a better design to allow specifying the encoding per column? That would give you more flexibility. I know that NCHAR/NVARCHAR is SQL Standard, but as I still think that it is a wart. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: