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
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 |
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 |