From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: User's exception plpgsql |
Date: | 2005-07-26 04:48:36 |
Message-ID: | Pine.LNX.4.44.0507260637070.18191-100000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Tue, 26 Jul 2005, Neil Conway wrote:
> Neil Conway wrote:
> > Not at the moment. I believe we have agreed that it would be better to
> > remove the concept of "exception variables" and just use strings, but I
> > haven't implemented this yet.
>
> BTW, one minor annoyance I noticed: a builtin condition name can
> actually map to multiple SQLSTATE values.
can you show sample, please?
If we allow a builtin
> condition name to be specified to RAISE, this means we'll actually need
> to pass around a list of SQLSTATE values that are thrown by the RAISE,
> rather than a single SQLSTATE. This seems pretty ugly, though --
> especially considering that only a handful of the builtin condition
> names actually do map to multiple SQLSTATEs. Does anyone have a better
> suggestion?
>
Exception variables can solve it, but its dead concept. We can have list
of prohibited condition names and for its throw compile error
condition name is ambigous
Pavel
> -Neil
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-07-26 04:57:59 | Re: User's exception plpgsql |
Previous Message | Larry Rosenman | 2005-07-26 04:26:47 | Re: regression failure on latest CVS |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-07-26 04:57:59 | Re: User's exception plpgsql |
Previous Message | Neil Conway | 2005-07-26 01:41:10 | Re: User's exception plpgsql |