Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions
Date
Msg-id 200606162215.k5GMFMY23357@candle.pha.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If we go with that how does the caller check between not found and too
> > many?  And if we go with Oracle names, I need different codes to match
> > with the two Oracle names.
> 
> I think we should just go with two new codes and use the Oracle names
> for them.  One remaining question: shall we assign codes in class 21
> (Cardinality Violation) or class P0 (PL/pgSQL Error)?  If you think
> these are likely to be used in other places then class 21 seems
> reasonable, but if we are thinking of them as being Oracle compatibility
> hacks then I'd lean to class P0.

Oracle-only, I would think, but I am no Oracle expert (never used it,
actually (a badge of honor?)).

> 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?

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if
Next
From: Arjen van der Meijden
Date:
Subject: Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL community