Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group