Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support - Mailing list pgsql-committers

From Pavel Stehule
Subject Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support
Date
Msg-id Pine.LNX.4.44.0505261759030.3234-100000@kix.fsv.cvut.cz
Whole thread Raw
In response to Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support (Really Oracle behavior)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
>
> That might be taking the notion of bug-compatibility with PL/SQL
> a bit too far.  For that matter, did you check whether Oracle
> actually treats it as a procedure-scope variable?  Try having the
> exception block call another function and trap an error inside that.
> Does SQLCODE change in the calling function?
>

good shot. Its more like session (global) variable.

create function foo2
return integer
as
begin
  dbms_output.put_line('10: '||SQLCODE||' -> '||SQLERRM);
  raise_application_error(-20003, 'Third exception');
end;

change of foo

   dbms_output.put_line('3: '||SQLCODE||' -> '||SQLERRM);
   --raise_application_error(-20002, 'Second exception');
   f := foo2;
  exception when others then
      dbms_output.put_line('4: '||SQLCODE||' -> '||SQLERRM);
  end;

and result:

1: 0 -> ORA-0000: normal, successful completion
2: -20001 -> ORA-20001: First exception
3: -20001 -> ORA-20001: First exception
10: -20001 -> ORA-20001: First exception
4: -20003 -> ORA-20003: Third exception
5: 0 -> ORA-0000: normal, successful completion
6: 0 -> ORA-0000: normal, successful completion

foo2 knows first exception. Is it bug? Maybe. The exception was outside
function, not in function and expected value of SQLCODE is zero.

Pavel


pgsql-committers by date:

Previous
From: Barry@awebbiz.com
Date:
Subject: aWebBiz Newsletter - AdSense Followup
Next
From: Pavel Stehule
Date:
Subject: Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support