Re: A bad behavior under autocommit off mode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Barry Lind <blind(at)xythos(dot)com>, 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-21 15:40:08
Message-ID: 13026.1048261208@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2003-03-21 15:40:59 Re: ALTER TABLE / CLUSTER ON
Previous Message Alvaro Herrera 2003-03-21 15:38:59 Re: ALTER TABLE / CLUSTER ON