Re: User's exception plpgsql

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>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: User's exception plpgsql
Date: 2005-07-26 06:00:24
Message-ID: 42E5D178.8020404@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ohp 2005-07-26 13:47:47 Re: regression failure on latest CVS
Previous Message Tom Lane 2005-07-26 05:17:11 Re: User's exception plpgsql

Browse pgsql-patches by date

  From Date Subject
Next Message Matthew T. O'Connor 2005-07-26 15:45:19 Re: [HACKERS] Autovacuum loose ends
Previous Message Tom Lane 2005-07-26 05:17:11 Re: User's exception plpgsql