From: | Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: encoding of PostgreSQL messages |
Date: | 2009-02-08 23:03:14 |
Message-ID: | 498F64B2.8070401@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Bruce Momjian wrote:
>>> Can someone comment on this?
>
>> Looks like a horrible hack to me. Recoding stuff to the client encoding
>> in the server outside the existing recoding mechanism looks pretty evil
>> to me. Plus, it does not address the problem of what happens to
>> messages sent before this, it just moves the point of "before" a bit
>> earlier for some special cases.
>
>> I think we have discussed more proper solutions earlier in this thread.
>> IMO the best approach would be for the client to include the client
>> encoding in the startup package.
>
> Huh? Clients already do that (or at least some are capable of it,
> including libpq).
Yes the psqlodbc driver has done it because protocol 3 allowed it
from the first.
> The hard problems are (1) there's still a "before",
Yes but isn't it an improvement that properly localized password error
or no database error etc can be seen? Currently I see unreadable
error messages for those cases via psqlodbc driver. The attatched
patch in my previous posting is an example to solve the problem.
regards,
Hirosh Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Magoffin | 2009-02-09 03:32:45 | Out of memory on SELECT in 8.3.5 |
Previous Message | Ivan Sergio Borgonovo | 2009-02-08 19:50:54 | Re: [findings] minimal open source e-commerce software for pg |