AW: [HACKERS] TRANSACTIONS

> Jose Soares <jose@sferacarta.com> writes:
> > -------------------------------------------------------
> > Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
> > -------------------------------------------------------
> > connect  hygea.gdb;
> > create table temp(a int);
> > insert into temp values (1);
> > insert into temp values (1000000000000000000000000000000000);
> > commit;
> > select * from temp;
>
> > arithmetic exception, numeric overflow, or string truncation
>
> >           A
> > ===========
> >           1
>
> > I would like to know what the Standard says and who is in the rigth path
> > PostgreSQL or the others, considering the two examples reported below.
>
> I think those other guys are unquestionably failing to
> conform to SQL92.
> 6.10 general rule 3.a says

All others also throw an error for this statement, and thus conform.
As you can see from the select only the first row is inserted.
I think the numeric is only an example of an error, it could also be
any other error, like "duplicate key" or the like.

> ......
>
> and 3.3.4.1 says
>
>          The phrase "an exception condition is raised:", followed by the
>          name of a condition, is used in General Rules and elsewhere to
>          indicate that the execution of a statement is unsuccessful, ap-
>          plication of General Rules, other than those of Subclause 12.3,
>          "<procedure>", and Subclause 20.1, "<direct SQL statement>", may
>          be terminated, diagnostic information is to be made available,
>          and execution of the statement is to have no effect on SQL-data
or

Note here, that they say "the statement", which does not say anything about
other statements in the same transaction.

>          schemas. The effect on <target specification>s and SQL descriptor
>          areas of an SQL-statement that terminates with an exception
condi-
>          tion, unless explicitly defined by this International Standard,
is
>          implementation-dependent.
>
> I see no way that allowing the transaction to commit after an overflow
> can be called consistent with the spec.

Of course it can not commit this single statement that was in error.
All he wants is to commit all other statements, before and after the
error statement inside this same transaction.

Andreas