Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if
Date: 2006-06-16 23:02:05
Message-ID: 1606.1150498925@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Actually ... does Oracle have SQLSTATEs assigned to these errors?
>> If so, maybe we should use theirs. I had the idea they were still
>> stuck on non-spec-compatible error numbers, though.

> Anyone?

I did some googling and found one page that says no_data_found is
ORA-01403 and too_many_rows is ORA-01422. Another page said that
ORA-01403 maps to SQLSTATE 02000 (which is exactly what we need to
avoid to be spec-compliant) and they don't give a mapping at all
for ORA-01422 :-(. So once again, Oracle is totally useless as a
precedent for SQLSTATE choices.

I'll go with a couple of codes in the P0 class for the moment.
If anyone has a better idea, it won't be hard to change.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2006-06-16 23:29:27 pgsql: Code review for SELECT INTO STRICT patch: use saner choices of
Previous Message Tom Lane 2006-06-16 22:41:50 pgsql: Clean up after someone's curious idea that it'd be good to strip

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-06-16 23:24:16 Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL community
Previous Message Arjen van der Meijden 2006-06-16 22:34:20 Re: Sun Donated a Sun Fire T2000 to the PostgreSQL community