Re: problem with new autocommit config parameter and jdbc

On Wed, 11 Sep 2002, snpe wrote:

> On Wednesday 11 September 2002 04:58 am, Stephan Szabo wrote:
> > On Wed, 11 Sep 2002, snpe wrote:
> > > On Wednesday 11 September 2002 02:09 am, Stephan Szabo wrote:
> > > > On Wed, 11 Sep 2002, snpe wrote:
> > > > > yes, we're going around in circles.
> > > > >
> > > > > Ok.I agreed (I think because Oracle do different)
> > > > > Transaction start
> > > > > I type invalid command
> > > > > I correct command
> > > > > I get error
> > > > >
> > > > > Why.If is it transactin, why I get error
> > > > > I want continue.
> > > > > I am see this error with JDeveloper (work with Oracle, DB2 an SQL
> > > > > Server)
> > > >
> > > > Right, that's a separate issue (I alluded to it earlier, but wasn't
> > > > sure that's what you were interested in). PostgreSQL treats all errors
> > > > as unrecoverable. It may be a little loose about immediately rolling
> > > > back due to the fact that historically autocommit was on and it seemed
> > > > better to not go into autocommit mode after the error.
> > > >
> > > > I doubt that 7.3 is going to change that behavior, but a case might be
> > > > made that when autocommit is off the error immediately causes a
> > > > rollback and new transaction will start upon the next statement (that
> > > > would normally start a transaction).
> > >
> > > Why rollback.This is error (typing error).Nothing happen.
> > > I think that we need clear set : what is start transaction ?
> > > I think that transaction start with change data in database
> > > (what don't change data this start not transaction.
> >
> > Another interesting case for a select is, what about
> > select func(x) from table;
> > Does func() have any side effects that might change data?
> > At what point do we decide that the statement needs a
> > transaction?
> Function in select list mustn't change any data.
> What if function change data in from clause ?

There is no such restriction. The behavior is not necessarily
well defined in all cases, but postgresql certainly doesn't
require that the functions not change data especially given
that postgresql takes:
select func();
as the way to call to func();
Example session from 7.3 just pre-beta included below.

----

sszabo=# create table b(a int);
CREATE TABLE
sszabo=# create table a(a int);
CREATE TABLE
sszabo=# create function f(int) returns int as 'insert into b values ($1);
select $1;' language 'sql';
CREATE FUNCTION
sszabo=# insert into a values (1);
INSERT 17010 1
sszabo=# select f(a) from a;
f
---
1
(1 row)

sszabo=# select * from b;
a
---
1
(1 row)