Re: User's exception plpgsql - Mailing list pgsql-patches

From Tom Lane
Subject Re: User's exception plpgsql
Date
Msg-id 23312.1122355031@sss.pgh.pa.us
Whole thread Raw
In response to Re: User's exception plpgsql  (Neil Conway <neilc@samurai.com>)
Responses Re: User's exception plpgsql  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.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

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: User's exception plpgsql
Next
From: Neil Conway
Date:
Subject: Re: User's exception plpgsql