Re: plpgsql raise - parameters can be expressions

Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> writes:
> Next problem, visibility custom exceptions. When I define exception
> variable I can't rethrown exceptions outside block when is defined. What
> is outside - some custom exception?

I don't think this is an issue. A custom exception is really just a
name for a SQLSTATE value, so you can throw it in any case. An outer
block that does not know that name can only catch it as WHEN OTHERS,
but so what?

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 ...

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.

> 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 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 ] ;

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.

regards, tom lane