Re: Why are default encoding conversions

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Why are default encoding conversions
Дата
Msg-id 20060329.010908.62373559.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Why are default encoding conversions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why are default encoding conversions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Why are default encoding conversions  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
> Tatsuo Ishii <ishii@sraoss.co.jp> writes:
> > I'm sure we need more than one default conversion for encoding A and
> > B. For example, different vendors provide different conversion maps
> > for SJIS and UTF-8. M$ has its own and Apple has another one, etc. The
> > differences are not huge but some customers might think the difference
> > is critical. In this case they could create their own conversion in
> > their schema.
> 
> Well, being able to switch to a different conversion is fine, but I don't
> think that's a good argument for tying it to the schema search path.
> What would make more sense to me is a command specifically setting the
> conversion to use --- perhaps a GUC variable, since then ALTER USER SET
> and ALTER DATABASE SET would provide convenient ways of controlling it.

If it does work, then it's ok. However still I'm not sure why current
method is evil.

BTW, what does the standard say about conversion vs. schema? Doesn't
conversion belong to schema? If so, then schema specific default
conversion seems more standard-friendly way.
--
Tatsuo Ishii
SRA OSS, Inc. Japan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Tru64/Alpha problems
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: [GENERAL] PANIC: heap_update_redo: no block