"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> I like this syntax, but I am not if it's good idea add new similar
> statement. I don't know - but maybe it's can be better then extending
> RAISE - and way to get consensus.
I looked a bit more at the SQL spec. It already defines a <condition
information item name> MESSAGE_TEXT, which arguably is what we should
use for the primary message item, but that seems unpleasantly long for
something that's going to be used in pretty much every SIGNAL command.
Also there's a question of whether it's supposed to mean the *complete*
message delivered to a client, which would subsume DETAIL, HINT, etc
in our scheme. So I'm a bit tempted to stick with MESSAGE, DETAIL,
and HINT as the settable options if we go with SQL/PSM-derived syntax.
We'd also want LEVEL or something to be able to specify non-ERROR
elog levels.
Also, as to the re-throw-an-error capability, SQL/PSM defines a RESIGNAL
command that does this. I propose implementing only the parameterless
variant of this, at least for the time being. (The spec appears to
intend that RESIGNAL can override selected fields of the error being
re-thrown, which doesn't strike me as a terribly good idea --- you could
end up with a completely nonsensical error report.)
regards, tom lane
