From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Andreas Pflug" <Andreas(dot)Pflug(at)web(dot)de>, <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: [Fwd: pgadmin3 clientencoding] |
Date: | 2003-06-10 10:10:00 |
Message-ID: | 03AF4E498C591348A42FC93DEA9661B844B010@mail.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas(dot)Pflug(at)web(dot)de]
> Sent: 10 June 2003 09:46
> To: pgadmin-hackers(at)postgresql(dot)org
> Subject: [pgadmin-hackers] [Fwd: pgadmin3 clientencoding]
>
> Additionally, I wonder if there's an individual client encoding
> necessary for tree display; I believe it's sufficient for it to be
> Unicode to support all possible encodings. Think of a situation where
> one SQL_ASCII and one EUC_JP database are residing on the
> same server.
> Because there's no way to convert back and forth, it's not
> possible to
> display the second database if the first is retrieved using
> its native
> encoding.
Hmm, good point. Perhaps we should just say Unicode all the time then
when we have a Unicode build.
>
> Do we really need special encodings, besides unicode? If so,
> this should
> be implemented on a tree node (Server property: client
> encoding) to make
> it possible to let the change of encoding have immediate
> effect, or as
> the "System Object" setting is implemented.
No, because then you are mixing schema with commands that may affect the
schema in non-obvious ways.
Regards, Dave.
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2003-06-10 12:00:39 | Re: pgadmin3 clientencoding |
Previous Message | Andreas Pflug | 2003-06-10 09:39:29 | Re: pgadmin3 clientencoding |