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 22:08:01
Message-ID: 1251.1150495681@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:
> 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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-16 22:08:46 pgsql: Add: > o Allow PL/python to composite types and result sets >
Previous Message Bruce Momjian 2006-06-16 22:05:01 pgsql: Add: > > * Fix CREATE CAST on DOMAINs > >

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-16 22:15:22 Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions
Previous Message Bruce Momjian 2006-06-16 22:05:06 Re: bug? non working casts for domain