Re: A bad behavior under autocommit off mode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Barry Lind <blind(at)xythos(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A bad behavior under autocommit off mode
Date: 2003-03-22 23:23:25
Message-ID: 3302.1048375405@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The silent assumption behind the client_encoding parameter is that you
> must set it to the actual character set encoding used by the client. If
> you lie, the results are unspecified. So if you're in a JDBC application
> and set the client encoding to an encoding that the JDBC driver (that is,
> "the client") cannot handle, you lied and you deserve to lose.

I think the issue is not so much whether the JDBC driver *can* handle
the encoding, as whether it knows what it needs to be doing right now.

> There are real and valid reasons for changing the client encoding on the
> fly, but that is no reason to make a big deal about passing the
> information around all the time.

If the JDBC driver needs to do anything different for one encoding than
another, then it needs to be informed of changes. We can debate what's
the most appropriate way to keep it informed, but I don't think we can
just ignore the need to inform it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-03-22 23:35:59 Re: PQescapeBytea on Win32
Previous Message Peter Eisentraut 2003-03-22 23:08:38 Re: A bad behavior under autocommit off mode