Re: [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

            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