Re: User's exception plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, pgsql-patches(at)postgresql(dot)org
Subject: Re: User's exception plpgsql
Date: 2005-07-06 17:09:39
Message-ID: 28184.1120669779@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2005-07-06 17:12:54 Re: User's exception plpgsql
Previous Message Pavel Stehule 2005-07-06 16:52:21 Re: User's exception plpgsql

Browse pgsql-patches by date

  From Date Subject
Next Message Pavel Stehule 2005-07-06 17:12:54 Re: User's exception plpgsql
Previous Message Pavel Stehule 2005-07-06 16:52:21 Re: User's exception plpgsql