Re: A bad behavior under autocommit off mode

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Well, the jdbc guys like SET, and I haven't seen any proposal that
> > explains how applications would control a client-based autocommit API
> > from the client.
>
> libpq is the only client library that doesn't already *have* an API spec
> for this. SET is not helpful for any of the rest because it is not the
> spec they need to meet.

True, but we have 7+ interfaces based on libpq.

> > Very true. The only other environment variable I have heard about was
> > client encoding. As I remember right now, we do have a problem with SET
> > changing the client encoding, and the client not realizing that.
>
> Hm. Is anyone else very concerned about that? The design roadmap I put
> forward last week suggested reporting client encoding and autocommit
> status during the initial connection handshake, but not after every
> query. Neither of those seem like things that are sensible to change
> on-the-fly during a session.

Well, we do have this problem mentioned in the psql \encoding manual
page:

This command will not notice changes made directly by <command>SET
CLIENT_ENCODING</>. If you use <literal>\encoding</literal>,
be sure to use it to set as well as examine the encoding.

Not sure if it is worth fixing, but I thought I should mention it,
especially if people can think of other problem cases.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073