Re: Syntax decisions for pl/pgsql RAISE extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Syntax decisions for pl/pgsql RAISE extension
Date: 2008-05-12 19:47:08
Message-ID: 25109.1210621628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-05-12 19:52:27 Re: bloated heapam.h
Previous Message Magnus Hagander 2008-05-12 19:47:03 Re: [COMMITTERS] pgsql: Convert wal_sync_method to guc enum.