Re: plpgsql raise - parameters can be expressions

>
> I would also expect that matching is by SQLSTATE, that is if I write
>
> DECLARE foo EXCEPTION = '12345';
> ...
> RAISE ERROR foo, ...;
>
> then some outer block written as
>
> DECLARE bar EXCEPTION = '12345';
> ...
> EXCEPTION WHEN bar THEN ...
>

if we accept exception is like variable, then there is rules for
variables. I don't see problem there.

EXCEPTION WHEN bar is equivalent of

EXCEPTION SQLSTATE = 12345 THEN

where I see bar, I can see bar. But isn't possible two exception handlers
in one block with one SQLSTATE.

> would catch this error.
>
> > disadvantage - I have to define format string everywhere where I wont to
> > raise exception.
>
> Why is that a disadvantage? You should not be able to throw an error
> without providing a useful message --- that's just basic good
> programming.
>

it's ok. Exception without error message is wrong. One type of exception
with different error messages (parametrized message is ok) is wrong too.
But it's my personal opinion. Maybe one message string is not sufficient,
better is message string and hint string (like now).

> > From OOP view exception is object. But I need define more properties than
> > one. SQLSTATE is only first, second message, level, meybe next
>
> I think we are better off defining exception names as SQLSTATEs and
> nothing else. That's essentially how we have done it in the backend
> code and it has worked well over a very large body of code. You are
> arguing for a less flexible definition on the basis of nothing more
> than a vague appeal to "OOP principles". You have neither stated
> exactly which principles nor exactly why they dictate this choice,
> so I see nothing convincing in your argument.

I have less. All is only my ideas. I don't wont PLPGSQL like full OOP
language. I speak only about possible ways now. I see usefull global
definition of exception on package (or schema, database) level - like
others db objects (sequences). Packages not exists and all is in future.
On procedural level I have to agree with you. Your syntax don't exude
"my" syntax.

If I choise level, format_string,.. in raise stmt, then are used this
params. If not, then are used default parames (in future).

> > I think so we need more then one exception level. I can use
> > user's exception for easy way of write to log.
>
> Well, can we get away with making the syntax be
>
> RAISE level [ exception_name , ] format_string [ , parameters ] ;
>

I agree. I unlike big steps.

About level: I think so already defined levels are good. I have idea about
somethink between levels NOTICE and EXCEPTION. I can't catch NOTICE and I
have to catch EXCEPTION, maybe RAISE EVENT. I can catch it, if I wont. And
this level don't rollback transaction, and should be return back from
exception handler. It's more like calling subrutine. Can be usefull.

Question: What do you think about

I specify minimal level of event in log. But when I have user's exception
I can specify list of user's exception for log.

like

log_level NOTICE
log_exceptions myexception1, myexception2, ...

> where "level" is one of the already-defined level keywords? Normally
> I would think that this would be unacceptably ambiguous, but as long as
> the exception_name is constrained to be either a built-in or previously
> defined exception name, this is probably workable from a syntactic point
> of view.

Pavel Stehule