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

Re: User's exception plpgsql

From: Neil Conway <neilc(at)samurai(dot)com>
To: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>
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 05:03:26
Message-ID: 42E5C41E.1060805@samurai.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Pavel Stehule wrote:
> can you show sample, please?

modifying_sql_data_not_permitted, null_value_not_allowed, 
prohibited_sql_statement_attempted and reading_sql_data_not_permitted 
are the examples I can see from scanning plerrcodes.h. If we had this to 
do over again, I'm not sure I see the point in mapping a single 
condition names to multiple SQLSTATEs, but it's probably too late to 
undo that now.

> 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

Yeah, that's possible, but it doesn't seem any nicer :-(

-Neil

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-07-26 05:17:11
Subject: Re: User's exception plpgsql
Previous:From: Alvaro HerreraDate: 2005-07-26 04:59:14
Subject: Re: [HACKERS] Autovacuum loose ends

pgsql-patches by date

Next:From: Tom LaneDate: 2005-07-26 05:17:11
Subject: Re: User's exception plpgsql
Previous:From: Alvaro HerreraDate: 2005-07-26 04:59:14
Subject: Re: [HACKERS] Autovacuum loose ends

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