Neil Conway <[EMAIL PROTECTED]> 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

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

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

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to