Re: Syntax decisions for pl/pgsql RAISE extension - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Syntax decisions for pl/pgsql RAISE extension
Date
Msg-id 23346.1210615850@sss.pgh.pa.us
Whole thread Raw
In response to Re: Syntax decisions for pl/pgsql RAISE extension  ("Brendan Jurd" <direvus@gmail.com>)
Responses Re: Syntax decisions for pl/pgsql RAISE extension  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-hackers
"Brendan Jurd" <direvus@gmail.com> writes:
> I agree that the % formatting in the RAISE message is weird, but it is
> useful.

Sure, I'm not proposing removing it.

> What would we do if the user specifies a %-formatted message as well
> as a MESSAGE option?

Throw an error (just like if they specified the same option type twice).

> I like "RAISE condition_name", can we support it in conjunction with
> the current syntax?  That is:

>     RAISE level [condition] [string literal, [parameter, ...]] [USING
> [option = value, ...]]

Well, it's sort of a mess because level has to become optional in order
to be Oracle-compatible (or PSM-compliant, if Kevin is correct).  We
could get away with it only if the condition were not allowed to be
a string literal, which I guess is tolerable but it's a bit annoying.
It would get less annoying if we allowed user-declared exception names.
I find the Oracle syntax for those to be spectacularly awful:
DECLARE    deadlock_detected EXCEPTION;    PRAGMA EXCEPTION_INIT(deadlock_detected, -60); 

but it sounds like SQL/PSM's syntax isn't so bad.  I could live with
the reported
DECLARE   condition-name CONDITION FOR SQLSTATE VALUE character-literal

However, that's a separate feature and I don't want to get into it as
part of the current patch.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: XIDs and big boxes again ...
Next
From: "Pavel Stehule"
Date:
Subject: Re: Syntax decisions for pl/pgsql RAISE extension