Re: plpgsql raise - parameters can (ToDo)

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

In response to

Responses

Browse pgsql-patches by date

  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)