Re: User's exception plpgsql - Mailing list pgsql-patches

From Tom Lane
Subject Re: User's exception plpgsql
Date
Msg-id 28184.1120669779@sss.pgh.pa.us
Whole thread Raw
In response to Re: User's exception plpgsql  (Neil Conway <neilc@samurai.com>)
Responses Re: User's exception plpgsql
Re: User's exception plpgsql
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> I think it is a bad idea, if not actually impossible, to have an
>> expression for sqlstate with no separating syntax before the 'fmt';
>> especially not if you'd like to also allow an expression for the 'fmt'.

> I don't actually see much of a need to allow 'fmt' to be an expression,

Well, in any case we have a problem if there's no comma.  Consider

    RAISE NOTICE '12' !! '345', ...

Is !! an infix operator (using both strings as arguments) or a postfix
operator (in which case '345' is the format)?

> Another solution might be varying the syntax slightly, such as:

>      RAISE [ opt_sqlstate ] LEVEL 'fmt' [ , expr ... ]

This would require promoting all the options for LEVEL into fully
reserved words.  You really can't get around the fact that you need
something pretty identifiable to terminate the expression.

It might work to require parentheses:

    RAISE LEVEL ( sqlstate expression ), 'fmt' [, ...]

The comma after the right paren is optional from a formal point of view,
but I'd still consider it better design to use one than not.  (For one
reason, it would make it much easier to catch mismatched-parens problems.)

            regards, tom lane

pgsql-patches by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: User's exception plpgsql
Next
From: Pavel Stehule
Date:
Subject: Re: User's exception plpgsql