> 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.)
>
> Ideas?
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
BEGIN
RAISE my_exception; -- named exception; -- no params
EXCEPTION WHEN division_by_zero THEN
my_exception ~ division by zero
END;
----------or----------------
EXCEPTIO WHEN my_exception THEN
...
END
all variants are legal. I can use user's exception
with default unique value from predefined interval too.
DECLARE my_exception EXCEPTION;
regards
Pavel Stehule
p.s.
>
> 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
