John DeSoi <[EMAIL PROTECTED]> writes:
> On Feb 28, 2006, at 11:19 AM, Tom Lane wrote:
> What about the pg_hba.conf file? Is there a provision to specify the
> encoding or some other way to deal with non-ascii characters?
pg_hba.conf is also processed without any locale considerations,
ie, effec
On Feb 28, 2006, at 11:19 AM, Tom Lane wrote:
In any case I don't think there's a huge problem if we say that
database
and user names had better be chosen from the round-trip-safe subset.
What about the pg_hba.conf file? Is there a provision to specify the
encoding or some other way to de
On Tue, Feb 28, 2006 at 11:19:02AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> >>> This may be the only solution. Converting everything to UTF-8 has
> >>> issues because some encodings are not roundtrip-safe
>
> >> Is this still true?
>
> > I beleive so. If use the ICU Converter Ex
> Martijn van Oosterhout writes:
> >>> This may be the only solution. Converting everything to UTF-8 has
> >>> issues because some encodings are not roundtrip-safe
>
> >> Is this still true?
>
> > I beleive so. If use the ICU Converter Explorer [1] to
> examine some of
> > the encodings we su
Martijn van Oosterhout writes:
>>> This may be the only solution. Converting everything to UTF-8 has
>>> issues because some encodings are not roundtrip-safe
>> Is this still true?
> I beleive so. If use the ICU Converter Explorer [1] to examine some of
> the encodings we support, they have "Con
On Tue, Feb 28, 2006 at 12:05:17PM -0300, Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
>
> > This may be the only solution. Converting everything to UTF-8 has
> > issues because some encodings are not roundtrip-safe (Enc -> UTF8 -> Enc
> > gives you a different string than you started wit
Martijn van Oosterhout writes:
> However, my personal preference is to treat the name of the database as
> a "bunch of bits" ie, don't consider it encoded at all.
That's essentially what we are doing as far as the StartupMessage is
concerned. Doesn't really solve the problem of post-startup acce
On Feb 28, 2006, at 1:38 AM, Tom Lane wrote:
I could not find anything in the Frontend/Backend protocol docs
about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this
handled
when nothing yet has been said about
Martijn van Oosterhout wrote:
> This may be the only solution. Converting everything to UTF-8 has
> issues because some encodings are not roundtrip-safe (Enc -> UTF8 -> Enc
> gives you a different string than you started with). There's probably
> no encoding round-trip safe with every other encodi
On Tue, Feb 28, 2006 at 02:45:25PM +0800, Christopher Kings-Lynne wrote:
> >I don't see any very nice solution at the moment. Once we get support
> >for per-column locales, it might be possible to declare that the shared
> >catalogs are always in UTF8 encoding and get the necessary
> >conversions
I don't see any very nice solution at the moment. Once we get support
for per-column locales, it might be possible to declare that the shared
catalogs are always in UTF8 encoding and get the necessary
conversions to happen automatically.
At the very least, could we always convert dbnames and s
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I could not find anything in the Frontend/Backend protocol docs about
>> character encoding in the StartupMessage. Assuming it is legal for a
>> database or user name to have unicode characters, how is this handled
>> when nothing yet has be
I could not find anything in the Frontend/Backend protocol docs about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this handled
when nothing yet has been said about the client encoding?
A similar badness is that i
I could not find anything in the Frontend/Backend protocol docs about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this handled
when nothing yet has been said about the client encoding?
Thanks,
John DeSoi, Ph
On Tue, 10 Jun 2003, Peter Eisentraut wrote:
> we should try to keep the (translated) column headers within the client,
> to side-step this issue. Do you want to investigate that?
That is the obvious solution, there is no real need to send the strings to
the server in the first place.
The probl
Dennis Björklund writes:
> When you run psql with a different language then english the strings are
> usually in a character set that is not pure ascii. For example to
> represent swedish you need either latin1 or unicode. Therefor the po file
> for swedish is in latin1.
Yes, you need to set your
I've been playing with character encodings and found a problem/bug. I
still use 7.3.2, so it's possible (but I think not) that some of this have
been fixed.
When you run psql with a different language then english the strings are
usually in a character set that is not pure ascii. For example to
re
17 matches
Mail list logo
