Re: problem with new autocommit config parameter and jdbc

On Monday 09 September 2002 08:53 pm, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Barry Lind wrote:
> >> How should client interfaces handle this new autocommit feature? Is it
> >> best to just issue a set at the beginning of the connection to ensure
> >> that it is always on?
> >
> > Yes, I thought that was the best fix for apps that can't deal with
> > autocommit being off.
>
> If autocommit=off really seriously breaks JDBC then I don't think a
> simple SET command at the start of a session is going to do that much
> to improve robustness. What if the user issues another SET to turn it
> on?
>
> I'd suggest just documenting that it is broken and you can't use it,
> until such time as you can get it fixed. Band-aids that only partially
> cover the problem don't seem worth the effort to me.
>
> In general I think that autocommit=off is probably going to be very
> poorly supported in the 7.3 release. We can document it as being
> "work in progress, use at your own risk".
>

I'm use 'autocommit=false' and have problem with psql
When any commnad is lost, then next commnad get error for transactions
(simple select command).BTW

snpe> select * from org_ba;
ERROR: relation org_ba does not exists
snpe> select * from org_ban;
ERROR: current transactions is aborted, queries ignored until end of
transaction block
snpe> rollback;
ROLLBACK
snpe> select * from org_ban;

this command is ok.
regards
Haris Peco