Re: Re: Join with other database's table

Thank you.
I already decide to use Mule-Internal encoding. In fact, there is no
other choice. But I'm still not sure that I can solve my problem with
mule -internal encoding.

1. How can I copy(or backup) mule-internal encoded data. Mule-Internal
is for just back-end. If there is a table that have rows in many
different kind of language. I think, I could not back it up. Am I wrong?

2. I think Unicode is better then mule-internal. So, I will use unicode
encoding as soon as postgresql support automatic unicode translation. At
that time, should I translate mule-internal encoded table to unicode. (
I know there is positive side in mule-internal. One is It store string
with it's char set code. So I can distinguish the original char set of
character string. Another is postgresql use UTF-8 to store Unicode data.
It has a lot of over head when you encode CJK char. string.)

3. I don't know how postgresql sort mule-internal encoded data. Mule-
internal is not another char set. It just store 2 byte char  with it's
char set code. I mean it store 1 character(2bytes) in 3 bytes. I just
guess, postgresql may sort data by it's char set, first.

SL Baur  wrote:
>
> Sungchul Park <scpark@gen128.com> writes in pgsql-general@postgresql.org:
>
> > I am developing WWW site that is serviced in 4 difference language,
> > english, chinese, japanese, korean. I allocated one database for one
> > language. each DB will have same tables that have same kind of
> > information in different language. But I want to keep member's
> > information in one table.
>
> If you're using 7.0 you should be able to do this in one database if
> you select a multilingual database encoding.  I've tested mule_internal
> encoding and it works.  Unicode (UTF-8) encoding should also work,
> though there are no conversion routines to go from a Unicode database
> to an EUC Japanese client (for example).
>
>