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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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