On Thu, Jul 2, 2026 at 10:06 PM Henson Choi <[email protected]> wrote:
>>
>>
>> C. A nested DEFAULT can turn a hard error into a silent wrong answer.
>>
>> CREATE TABLE t(a text, b text);
>> INSERT INTO t VALUES ('foo', 'bar');
>>
>> SELECT CAST(CAST(a AS int DEFAULT b::int ON CONVERSION ERROR)
>> AS int2 DEFAULT -1 ON CONVERSION ERROR) FROM t;
>> -- -1
>>
>> The inner DEFAULT b::int (b = 'bar') fails at run time. At top level
>> the same failing DEFAULT raises:
>>
>> SELECT CAST('x' AS int DEFAULT ('zzz')::int ON CONVERSION ERROR);
>> -- ERROR: invalid input syntax for type integer: "zzz"
>>
>> Nested, it is instead taken for the outer cast's own conversion failure
>> and the outer DEFAULT (-1) is returned silently. A hard error becoming
>> a silent value is the concern here, independently of the DEFAULT policy
>> in (D).
>>
>>
For C:
I tried that in
https://www.postgresql.org/message-id/CACJufxH_1EtEBMb0JvxaM3Gmnt33HYrS37m5eYjJ_OfBkMVFJg%40mail.gmail.com
It seems infeasible to evaluate some subexpressions in an error-safe manner
while others are not. Therefore, if the top-level expression is error-safe, the
entire expression will compile to support error-safe evaluation for its
subexpressions as well.
For D, this is intended i suppose, see
https://www.postgresql.org/message-id/762ae707-7fdc-43d8-a77a-3a10d12ce21d%40postgresfriends.org
