Re: [GENERAL] Re: [HACKERS] TRANSACTIONS

Sorry for my english, Tom, but the point is another, I'm talking about
transactions not about error messages.
This is only a stupid example how to abort a transaction, PostgreSQL aborts
automatically transactions if
an error occurs, even an warning or a syntax error.
I can believe that all other databases are wrong and only we (PostgreSQL) are
right, but please try to understand me. This is not easy to believe anyway.
I'm looking for another database with a behavior like PostgreSQL but I can't find
it, and I tried a lot of them until now.
Do you know some database with transactions like PostgreSQL?

Tom Lane wrote:

> Jose Soares <jose(at)sferacarta(dot)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
>
> a) If SD is exact numeric or approximate numeric, then
>
> Case:
>
> i) If there is a representation of SV in the data type TD
> that does not lose any leading significant digits after
> rounding or truncating if necessary, then TV is that rep-
> resentation. The choice of whether to round or truncate is
> implementation-defined.
>
> ii) Otherwise, an exception condition is raised: data exception-
> numeric value out of range.
>
> 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
> 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.
>
> regards, tom lane
>
> ************

--
Jose' Soares
Bologna, Italy Jose(at)sferacarta(dot)com