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