Re: User's exception plpgsql

Neil Conway <neilc(at)samurai(dot)com> writes:
> I wonder if there is any point introducing the concept of an
> "exception variable" in the first place. What does it buy us over simply
> using a string?

Not a lot really, except for keeping things similar to the Oracle way of
doing it ... but that's a nontrivial consideration.

> RAISE LEVEL [ opt_sqlstate ] 'fmt' [, expr ... ]

> It might be slightly more difficult to parse this (especially if we
> allow 'fmt' to be an expression yielding a string, not just a string
> literal), but I don't think it is ambiguous and can be sorted out via
> yylex().

I think it is a bad idea, if not actually impossible, to have an
expression for sqlstate with no separating syntax before the 'fmt';
especially not if you'd like to also allow an expression for the 'fmt'.

At one point we had talked about

RAISE LEVEL [ opt_sqlstate, ] 'fmt' [, expr ... ]

The hard part here is that there isn't any very easy way to tell whether
you have a sqlstate, a fmt, and N exprs, or a fmt and N+1 exprs. The
saving grace of the declared-exception approach for this is that you
can tell by the datatype of the first argument expression which case you
have: if the expression yields text, it's a fmt, if it yields "exception"
(which we assume is an actual datatype) then it's a sqlstate.

We could handle "undeclared exceptions" in such a design by having a
function that converts text to an exception value:

RAISE LEVEL SQLSTATE('12345'), 'format here', ...

and maybe the short-term cheesy thing to do is special-case exactly this
syntax:

RAISE LEVEL [ SQLSTATE(text_expr), ] text_expr [, ... ]

which would give us the minimum functionality with a clear path to
expansion later.

regards, tom lane