Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
