From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | David Fiedler <david(dot)fido(dot)fiedler(at)gmail(dot)com> |
Subject: | Re: WHEN SQLSTATE '00000' THEN equals to WHEN OTHERS THEN |
Date: | 2025-03-20 16:04:19 |
Message-ID: | 1069227.1742486659@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
[ redirecting to -hackers ]
I wrote:
> David Fiedler <david(dot)fido(dot)fiedler(at)gmail(dot)com> writes:
>> I've stumbled across a code that used this condition, resulting in
>> unexpected behavior. I think it worths a note that catching 00000 is not
>> possible and that it results in a catch all handler.
> Hmph. The code thinks
> * OTHERS is represented as code 0 (which would map to '00000', but we
> * have no need to represent that as an exception condition).
> but it evidently didn't consider the possibility of a user writing
> '00000'. I'm more inclined to consider this a bug and change plpgsql
> to use something else internally to represent OTHERS. We could use
> -1, which AFAICS cannot be generated by MAKE_SQLSTATE.
Here's a patch for this. I'm unsure whether to change it in back
branches; is it conceivable that somebody is depending on WHEN
SQLSTATE '00000' mapping to WHEN OTHERS?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
make-OTHERS-disjoint-from-sqlstates.patch | text/x-diff | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | noname stranger | 2025-03-20 16:06:50 | Re: Ambiguity in IS JSON description and logic |
Previous Message | Kirk Parker | 2025-03-20 14:22:14 | Re: Ambiguity in IS JSON description and logic |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-03-20 16:11:46 | Re: optimize file transfer in pg_upgrade |
Previous Message | Alvaro Herrera | 2025-03-20 15:52:57 | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |