On Monday 09 September 2002 08:53 pm, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
