Re: Syntax decisions for pl/pgsql RAISE extension - Mailing list pgsql-hackers

On Tue, May 13, 2008 at 2:53 AM, Tom Lane <tgl@sss.pgh.pa.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