Re: Why are default encoding conversions - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Why are default encoding conversions
Date
Msg-id 20060329.010908.62373559.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Why are default encoding conversions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tru64/Alpha problems
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [GENERAL] PANIC: heap_update_redo: no block