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
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
---------------------------(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
match
