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.  ("MauMau" <maumau307@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Leonardo Francalanci
Дата:
Сообщение: Re: Fast insertion indexes: why no developments
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Fast insertion indexes: why no developments