Message-ID: <42E5D178.8020404@samurai.com>
Date: Tue, 26 Jul 2005 16:00:24 +1000
From: Neil Conway <neilc@samurai.com>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050602)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <stehule@kix.fsv.cvut.cz>,
	Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-patches@postgresql.org
Subject: Re: User's exception plpgsql
References: <Pine.LNX.4.44.0507260637070.18191-100000@kix.fsv.cvut.cz>
	<42E5C41E.1060805@samurai.com> <23312.1122355031@sss.pgh.pa.us>
In-Reply-To: <23312.1122355031@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Those cases are for places where the spec defines similar cases under
> the error classes "SQL Routine Exception" and "External Routine Exception".
> You can blame me for having assumed that plpgsql didn't need to
> distinguish these cases.

Well, in and of itself, I agree it is probably better to combine similar 
SQLSTATEs into a single logical condition. However, considering the 
problem it poses for implementing RAISE with builtin condition names, 
IMHO it would be a net win to get rid of it, if we can't find a better 
solution.

> So I see no backwards-compatibility argument that we can't change
> this.  How would you want to do it better?

I would just change the mapping from condition names to SQLSTATEs to be 
one-to-one. If a client application does need to trap multiple SQLSTATEs 
for a logically similar condition, they can always specify "WHEN x OR y 
OR ..."

-Neil