Hi. Karsten-san.
Yeah, It was a problem unsolvable by the driver to relay.
although perseverance keeping without giving up!
--
arigatougozaimasu:-)
Regards,
Hiroshi Saito
- Original Message -
From: "Karsten Hilbert"
On Tue, Mar 03, 2009 at 12:35:37AM +0900, Hiroshi Saito wrote:
On Tue, Mar 03, 2009 at 12:35:37AM +0900, Hiroshi Saito wrote:
> Sorry very late reaction.
> I desire problem solution.
So do I :-)
Ganbatte !
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
Sent via pgsql-general mailing list (pgsql-gene
Hi.
Sorry very late reaction.
I desire problem solution.Therefore, one evidence
I tried jdbc program.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/connect_problem/jdbctestx.java
C:\home\HIROSHI>java jdbctestx
org.postgresql.util.PSQLException: FATAL: ???[??"postgres"??
On Wed, Feb 11, 2009 at 02:20:47PM +0900, Hiroshi Inoue wrote:
> Tom Lane wrote:
> > Hiroshi Inoue writes:
> >> I'm thinking of the following steps in the backend code.
> >
> >> 1.Set LC_MESSAGES to "C" until the client_encoding is
> >> determined.
I have tried that but it didn't work out for
On Thu, Feb 12, 2009 at 10:28:38PM +0900, Hiroshi Inoue wrote:
> >>> Reflecting on the bigger picture ... I would imagine that the vast
> >>> majority of existing applications depend on client_encoding settings
> >>> that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
> >>> jus
Tom Lane wrote:
> Peter Eisentraut writes:
>> Tom Lane wrote:
>>> Reflecting on the bigger picture ... I would imagine that the vast
>>> majority of existing applications depend on client_encoding settings
>>> that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
>>> just the def
On Wednesday 11 February 2009 18:00:31 Tom Lane wrote:
> Peter Eisentraut writes:
> > Tom Lane wrote:
> >> Reflecting on the bigger picture ... I would imagine that the vast
> >> majority of existing applications depend on client_encoding settings
> >> that come from postgresql.conf, ALTER USER S
Peter Eisentraut writes:
> Tom Lane wrote:
>> Reflecting on the bigger picture ... I would imagine that the vast
>> majority of existing applications depend on client_encoding settings
>> that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
>> just the default (== database encod
Tom Lane wrote:
I believe the only real "fix" is to guarantee that messages are sent
as untranslated ASCII until we have sent an encoding indicator at
the end of the startup sequence. Which has its own pretty clear
downside: no more translation of authorization failures.
We should process the
Tom Lane wrote:
Reflecting on the bigger picture ... I would imagine that the vast
majority of existing applications depend on client_encoding settings
that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
just the default (== database encoding). I don't think a solution that
p
Tom Lane wrote:
> Hiroshi Inoue writes:
>> I'm thinking of the following steps in the backend code.
>
>> 1.Set LC_MESSAGES to "C" until the client_encoding is
>> determined.
>> 2.When a client_encoding is specifed in the startup
>> message, bind the corrsponding codeset to the
>> textdomain
Hiroshi Inoue writes:
> I'm thinking of the following steps in the backend code.
> 1.Set LC_MESSAGES to "C" until the client_encoding is
> determined.
> 2.When a client_encoding is specifed in the startup
> message, bind the corrsponding codeset to the
> textdomain and set LC_MESSAGES to th
Tom Lane wrote:
> Peter Eisentraut writes:
>> Bruce Momjian wrote:
>>> Can someone comment on this?
>
>> 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?
Tom Lane wrote:
> Peter Eisentraut 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 p
On Sun, Feb 08, 2009 at 10:38:16AM -0500, Tom Lane wrote:
> I believe the only real "fix" is to guarantee that messages are sent
> as untranslated ASCII until we have sent an encoding indicator at
> the end of the startup sequence. Which has its own pretty clear
> downside: no more translation of
Peter Eisentraut 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
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 ju
Peter Eisentraut wrote:
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
messa
Can someone comment on this?
---
Hiroshi Inoue wrote:
> Hi,
>
> This topic seems to be related to the bug report
> [ODBC] Localized error messages, wrong charset
> .
>
> Bruce Momjian wrote:
> > Added to TODO:
> >
> >
Hi,
This topic seems to be related to the bug report
[ODBC] Localized error messages, wrong charset
.
Bruce Momjian wrote:
Added to TODO:
Improve encoding of connection startup messages sent to the client
Currently some authentication error messages are sent in
lient
> by current means.
>
> Thanks,
> Karsten
>
> On Thu, Jan 01, 2009 at 08:33:56PM +0200, Peter Eisentraut wrote:
> > Subject: Re: [GENERAL] encoding of PostgreSQL messages
> > User-Agent: KMail/1.9.9
> >
> > On Wednesday 31 December 2008 20:23:47 Tom L
sages in 7-bit
English until server_encoding can be retrieved by the client
by current means.
Thanks,
Karsten
On Thu, Jan 01, 2009 at 08:33:56PM +0200, Peter Eisentraut wrote:
> Subject: Re: [GENERAL] encoding of PostgreSQL messages
> User-Agent: KMail/1.9.9
>
> On Wednesday 31 December
On Wednesday 31 December 2008 20:23:47 Tom Lane wrote:
> > The proper fix is probably to include the client encoding in the
> > connection startup message.
>
> What of errors occurring before such an option could be applied?
Connection errors are handled by the client, which knows the client encod
> Hm, so maybe both Peter and Alvaro are right:
>
> 1) Setting the translation wrapper to a NOOP as early as possible.
>
> Thus, the first messages are sent in 7-bit ASCII English.
Despite being *marked* for translation and a translation
to exist in the .po file, that is.
Karsten
--
Sensat
> > The proper fix is probably to include the client encoding in the
> connection
> > startup message.
>
> What of errors occurring before such an option could be applied?
>
> I think that ultimately it's necessary to accept that there will be some
> window during connection startup where sendin
Peter Eisentraut writes:
> On Wednesday 31 December 2008 18:57:29 Karsten Hilbert wrote:
>> The solution is to find the right layer to take control of the encoding but
>> this is eventually only possible if the encoding is *known*. Thus the plea
>> for "7-bit-ascii English by default until the enc
> On Wednesday 31 December 2008 18:57:29 Karsten Hilbert wrote:
> > The solution is to find the right layer to take control of the encoding
> but
> > this is eventually only possible if the encoding is *known*. Thus the
> plea
> > for "7-bit-ascii English by default until the encoding *can* be kno
On Wednesday 31 December 2008 18:57:29 Karsten Hilbert wrote:
> The solution is to find the right layer to take control of the encoding but
> this is eventually only possible if the encoding is *known*. Thus the plea
> for "7-bit-ascii English by default until the encoding *can* be known".
> Going
> Karsten Hilbert writes:
> > On Mon, Dec 29, 2008 at 09:07:14AM -0300, Alvaro Herrera wrote:
> >> And I'm now wondering if we should delay initializing the translation
> >> stuff until after client_encoding has been reported.
>
> > Or else
>
> > - just don't pass those messages through gettext
Karsten Hilbert writes:
> On Mon, Dec 29, 2008 at 09:07:14AM -0300, Alvaro Herrera wrote:
>> And I'm now wondering if we should delay initializing the translation
>> stuff until after client_encoding has been reported.
> Or else
> - just don't pass those messages through gettext so they are
>
On Mon, Dec 29, 2008 at 09:07:14AM -0300, Alvaro Herrera wrote:
> > That would not quite be enough -- I am talking about
> > messages reported *during* auth, say
> >
> > FATAL: password authentication failed for user "postgres"
> >
> > or
> >
> > fe_sendauth: no password supplied
> >
>
Karsten Hilbert wrote:
> On Tue, Dec 23, 2008 at 06:45:17PM -0300, Alvaro Herrera wrote:
> > Hmm, isn't client_encoding reported in the startup packet sent by the
> > server, after auth?
>
> That would not quite be enough -- I am talking about
> messages reported *during* auth, say
>
> FAT
On Dec 23, 2008, at 4:24 PM, Karsten Hilbert wrote:
How can I programmatically detect which encoding a
PostgreSQL server I am trying to connect to sends back
messages -- before I connect (so client_encoding and
the pg_settings table are flat out).
I don't think there is a way because you can'
On Tue, Dec 23, 2008 at 06:45:17PM -0300, Alvaro Herrera wrote:
> > How can I programmatically detect which encoding a
> > PostgreSQL server I am trying to connect to sends back
> > messages -- before I connect (so client_encoding and
> > the pg_settings table are flat out).
>
> Hmm, isn't client
Karsten Hilbert wrote:
> Hi all !
>
> How can I programmatically detect which encoding a
> PostgreSQL server I am trying to connect to sends back
> messages -- before I connect (so client_encoding and
> the pg_settings table are flat out).
Hmm, isn't client_encoding reported in the startup packet
35 matches
Mail list logo
