Re: Why are default encoding conversions

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: ishii(at)sraoss(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why are default encoding conversions
Date: 2006-03-28 16:09:08
Message-ID: 20060329.010908.62373559.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-03-28 16:12:09 Re: [GENERAL] PANIC: heap_update_redo: no block
Previous Message Tom Lane 2006-03-28 16:02:50 Re: Tru64/Alpha problems