Re: WHEN SQLSTATE '00000' THEN equals to WHEN OTHERS THEN

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

In response to

Browse pgsql-docs by date

  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

Browse pgsql-hackers by date

  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