Re: plpgsql raise - parameters can be expressions

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, pgsql-patches(at)postgresql(dot)org
Subject: Re: plpgsql raise - parameters can be expressions
Date: 2005-06-15 07:46:35
Message-ID: 42AFDCDB.2030400@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:
> I would also expect that matching is by SQLSTATE, that is if I write
>
> DECLARE foo EXCEPTION = '12345';
> ...
> RAISE ERROR foo, ...;

BTW, is there any value in a separate "EXCEPTION" type? ISTM that an
exception is just a SQLSTATE, which is in turn just a string. A separate
exception type does simplify the parsing of RAISE, but I wonder if it
would be useful to be able to also allow specifying the SQLSTATE code as
a string literal.

> I think we are better off defining exception names as SQLSTATEs and
> nothing else.

That seems the right way to go to me.

> Well, can we get away with making the syntax be
>
> RAISE level [ exception_name , ] format_string [ , parameters ] ;
>
> where "level" is one of the already-defined level keywords?

I think we can. I don't see the point of inventing a new RAISE level for
exceptions with a custom SQLSTATE. For one thing, it would be useful to
be able to specify a custom SQLSTATE for a RAISE WARNING.

-Neil

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2005-06-15 07:47:27 Re: hash join: probe both inputs first
Previous Message Andreas Pflug 2005-06-15 06:32:28 Re: dbsize backend integration