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

Re: User's exception plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
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 05:17:11
Message-ID: 23312.1122355031@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Neil Conway <neilc(at)samurai(dot)com> writes:
> 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.

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.

A quick grep says that the only one of these codes being generated today
is
contrib/dblink/dblink.c:                     (errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED),
and that's for a "you should not do that" case, which it's very unlikely
anyone is specifically trapping for.  So I see no
backwards-compatibility argument that we can't change this.  How would
you want to do it better?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-07-26 06:00:24
Subject: Re: User's exception plpgsql
Previous:From: Neil ConwayDate: 2005-07-26 05:03:26
Subject: Re: User's exception plpgsql

pgsql-patches by date

Next:From: Neil ConwayDate: 2005-07-26 06:00:24
Subject: Re: User's exception plpgsql
Previous:From: Neil ConwayDate: 2005-07-26 05:03:26
Subject: Re: User's exception plpgsql

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