Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2005-07-26 04:57:59
Subject: Re: User's exception plpgsql
Previous:From: Larry RosenmanDate: 2005-07-26 04:26:47
Subject: Re: regression failure on latest CVS

pgsql-patches by date

Next:From: Pavel StehuleDate: 2005-07-26 04:57:59
Subject: Re: User's exception plpgsql
Previous:From: Neil ConwayDate: 2005-07-26 01:41:10
Subject: Re: User's exception plpgsql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group