From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: plpgsql raise - parameters can (ToDo) |
Date: | 2005-06-13 17:07:10 |
Message-ID: | 21548.1118682430@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-06-13 17:45:27 | Re: plpgsql raise - parameters can be expressions |
Previous Message | Pavel Stehule | 2005-06-13 17:01:13 | Re: plpgsql raise - parameters can (ToDo) |