| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:08:38 |
| Message-ID: | Pine.LNX.4.44.0303221737270.2352-100000@peter.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane writes:
> I had originally been thinking of reporting client_encoding as a field
> of some message sent only at backend startup. However, what if we send
> such a message whenever one of the variables it includes changes?
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. (Really,
this problem can only occur in applications that let random users enter
random commands or if a programmer is explicitly trying out forbidden
territory.)
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.
--
Peter Eisentraut peter_e(at)gmx(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-03-22 23:23:25 | Re: A bad behavior under autocommit off mode |
| Previous Message | elein | 2003-03-22 21:22:40 | Fwd: [GENERAL] statement id |