On Tue, May 13, 2008 at 2:53 AM, Tom Lane <tgl@[EMAIL PROTECTED]
> 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 ere****t 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 re****t components
> in the same fa****on. 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 sup****t adding the MESSAGE option (again, nice symmetry with
ere****t), 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 sup****t 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 sup****t 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 sup****t it in conjunction with
the current syntax? That is:
RAISE level [condition] [string literal, [parameter, ...]] [USING
[option = value, ...]]
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
