Re: Syntax decisions for pl/pgsql RAISE extension

On Tue, May 13, 2008 at 2:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 1. The parentheses around the USING list seem useless; let's drop 'em.

Yes.

>
> 2. I think the separation between SQLSTATE and CONDITION is just
> complication. A SQLSTATE is required to be exactly 5 digits and/or
> upper case ASCII letters; I see no realistic prospect that any condition
> name would ever look like a SQLSTATE (and we could certainly adjust
> condition names to prevent it, if anyone would make such an unhappy
> choice). So I think we could unify these options into one. I think
> CODE might be a better choice for the option name than SQLSTATE (since
> the latter already has a meaning in pl/pgsql, ie the function that
> gives you the code for the currently thrown error) --- thoughts?
>

Yes. CODE has a nice symmetry with the use of errcode in ereport as well.

> 3. I think we should allow the user to specify the error message the
> same way as the other options, that is
> RAISE level USING MESSAGE = string_expression [ , ... ]
> The %-format business has always struck me as a bit weird, and it's
> much more so if we aren't handling the other error report components
> in the same fashion. So we ought to provide an alternative that's
> more uniform.
>

I agree that the % formatting in the RAISE message is weird, but it is
useful. When you're writing an exception message you almost always
want to substitute in information about the values (causing|involved
in) the exception. With MESSAGE = string you would have to
concatenate the pieces together with ||, which is longer and less
readable.

I support adding the MESSAGE option (again, nice symmetry with
ereport), but will probably continue to use the %-formatted message
style in my applications.

What would we do if the user specifies a %-formatted message as well
as a MESSAGE option? I think it would be reasonable to bail out with
a message explaining that they should use the formatted message XOR
the MESSAGE option.

> Now, the elephant in the room is the issue of Oracle compatibility.
> None of this looks anything even a little bit like Oracle's RAISE
> command. Oracle allows
> RAISE exception_name ;
> RAISE ;
> where the second case is allowed only in an EXCEPTION handler and
> means to re-throw the current error. I think the latter is a very
> good idea and we ought to support it. Right now there's no way to
> re-throw an error without information loss, and that'll get a lot
> worse with these additions to what RAISE can throw.

Yes! I've wished for a re-throw ability several times in the past.

> I'm less
> excited about the condition-name-only syntax; that seems awfully
> impoverished given the lack of any way to supply a specific error
> message or data values. Still, we could imagine people wanting
> something like
> RAISE condition_name USING message = string_expression
> where the condition_name would substitute for the CODE option.
> I think we could support this as long as the condition name were
> given as an exception name rather than a string literal (otherwise
> it looks too much like our legacy syntax). Comments? Is anyone
> excited about that one way or the other?

I like "RAISE condition_name", can we support it in conjunction with
the current syntax? That is:

RAISE level [condition] [string literal, [parameter, ...]] [USING
[option = value, ...]]

Cheers,
BJ