Re: plpgsql raise - parameters can (ToDo) - Mailing list pgsql-patches

From Tom Lane
Subject Re: plpgsql raise - parameters can (ToDo)
Date
Msg-id 21548.1118682430@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql raise - parameters can (ToDo)  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
Responses Re: plpgsql raise - parameters can (ToDo)  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
List pgsql-patches
Pavel Stehule <stehule@kix.fsv.cvut.cz> writes:
>   declare myexcept exception = 'xxxxx';
>   begin;
>     assoc(myexcept, 'my message % % %');
>     raise myexcept, param1, param2, ...

Our experience in writing the backend is that hard-wiring a single error
message text for a SQLSTATE code is the wrong thing.  The SQLSTATE codes
are relatively coarse-grained (which is usually the right thing from the
perspective of an application trying to match a SQLSTATE) and there is
very often room for the text message to give more detail than the
SQLSTATE alone conveys.

Also, the above seems highly error prone to me since it decouples the
format string from the parameters.  This is even worse for built-in
exception codes since the writer of a plpgsql function shouldn't assume
that he knows exactly what % parameters a built-in exception's format
string would use.

So for all these reasons, I think that only the SQLSTATE should be
associated with the exception name.  The format string should be part
of the RAISE command.

            regards, tom lane

pgsql-patches by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql raise - parameters can (ToDo)
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql raise - parameters can be expressions