> That doesn't bother me either, seeing that an undefined variable isn't
> detected at compile time anywhere else. However, fixing the SQLSTATE
> tests by removing them doesn't seem like a great solution ...
> > BTW, another easy improvement in this area is changing the RAISE format
> > string to allow it to be an expression, rather than only a string literal.
> I would sort of have expected this to get done at the same time.
> Actually, the reason I didn't do something about RAISE in 8.0 was that
> I thought we should reconsider the whole design of the statement: it
> desperately needs to be fixed so that you can specify the SQLSTATE to
> be thrown, and so that you can re-throw the same exception you caught.
> (Note that SQLERRM is not really a solution to that: you might think
> something like "RAISE EXCEPTION SQLSTATE, '%', SQLERRM" would do,
> but it loses information, namely all the auxiliary fields.)
only RAISE? Without parameters can be used only in block. It's same scope
like SQLERRM and SQLSTATE.
Oracle can define variables with type EXCEPTION. This all what we need -
identificator. For value of exception Oracle use PRAGMA EXCEPTION_INIT -
for SQLCODE value. PostgreSQL don't suport SQLCODE, then PRAGMA is
irelevant, but what:
DECLARE my_exception EXCEPTION = '22012'; -- division by zero
RAISE my_exception; -- named exception; -- no params
EXCEPTION WHEN division_by_zero THEN
my_exception ~ division by zero
EXCEPTIO WHEN my_exception THEN
all variants are legal. I can use user's exception
with default unique value from predefined interval too.
DECLARE my_exception EXCEPTION;
> regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match