Re: User's exception plpgsql

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
>

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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