Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vMLde-007GvH-3C for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Nov 2025 07:33:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vMLdd-0068R5-0a for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Nov 2025 07:33:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vMLdc-0068Qx-2H for pgsql-hackers@lists.postgresql.org; Fri, 21 Nov 2025 07:33:01 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vMLda-000f0w-0i for pgsql-hackers@lists.postgresql.org; Fri, 21 Nov 2025 07:32:59 +0000 Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-4332ae0635fso6596645ab.2 for ; Thu, 20 Nov 2025 23:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763710378; x=1764315178; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ek9Z7HWRpXtkZdc3Zf1RV55Qs+gCdTHpvE7RFaRCaoQ=; b=KO0Bsf81gV8rWrZXYbmPM5YykqIDHoz4EbYZB1LPzE1Wb+fS/1NQrfLlxQV0laH/ae fDR893BFlmSLOES8Fuq4PV8R0F43mvlHQXxwitCMzpzOqmUj580tJmqFmWskVJr7RMVZ FnKowdp2/ywGkzZGt+FIckVv4Fq91rAxbMB2vvg848GIOEk+2hynm0qE9hY+k48dd7rs EKsiwEOF7xl2vopl1qXR+LqYadBRjJ/TE0boMYptXoUhdc2pOGyMz+0gj7TVMipitqas wr1DOnMd5MFiRgHn9n9044+sRhdjrDAIpp5fyIxmVQeM1nzBJJahTfxYd+x7lLEF0HBp xGyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763710378; x=1764315178; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ek9Z7HWRpXtkZdc3Zf1RV55Qs+gCdTHpvE7RFaRCaoQ=; b=wsvSqQ+VGuyrqlcoEPG0RdbCA7Px1wdg0aipgkH789eCw2o9OiE3S00+fJJEfjLTS8 tLwlGa6rle/GKNPImbCYi0RYtN8xzujKDR/PkyTqMPaBmXf4NhrNH8m+wuxr+sOe0COy VU1p+PjPHtdf8KNmJ8+1WyK6vi2NN8PeuO/hQRMzIu6mLpm/AEX0DF4DtV44BSnCtYNJ W/gvU4aZC+tsN96nWNkY1KJsa64uxiW9lZXAzOCiLf6wHiG0E8PFPMcP3o6/12z/BUe8 kE52Pg9xsk9OIqleX/B99adWRKI0X81do6MxWCOZRXpHa5qecW/nPeuEO0g67O9BQJgp zHGw== X-Forwarded-Encrypted: i=1; AJvYcCWNqHFpN1TZnwGs2jDTdiuLmteDAFR6/3elM9XzpU5++Q5cTBw390DmkcGvFGo5qWWaBQ0Xqk3ettHez/x0@lists.postgresql.org X-Gm-Message-State: AOJu0YzamzRYTkBsPjXh5Dla7yX0zLna39OIFSmsGYUzJFjxzz2qnLwd ldFaG3Pm59OzrPDgXVZz3cmu9sgxOKlD4QPeDcvoGquCv1zieT/68iT5/g+U0SPT6EdOk5ptBYV WdPMprmohU9svTpCCvbH8XscUL1rO0tI= X-Gm-Gg: ASbGncudUACKZfEE4h0LUEXmOr+6ZgRBNEBx/MxH8hHdnxntlbO4GDHjxj+AY2BMNrc egXnJqi3QRarsyMnDr8fB6Y2sDUJeXwJRf+MgFCZ0r7Rcesy8vl5mHXvywsg8caBPKtdNTEik5Q hvT5Vzc+Bg9CEY8k/oExFoYn6n3IPBlviUamNLbbY5as84LcBHjPkK1QkwrMRcHlC8A6PKIzEyf IHj8TnVD2FAxjOF0qMuDE+/3+GkEDyUdyCITjPhxhQhm+NNkkzhwULXbr/eIXrP3lecsSY+U9Wg H8WCJZjjm6mak+Scu8NRw+kwJak= X-Google-Smtp-Source: AGHT+IFz5O3/EFDntrmfkl/ZUSPeVpoKGamdsY40YrKM1ZgHWJyaT6aalOiiodBJFfvpoksM/K0A8ntPp+A4Am++55A= X-Received: by 2002:a05:6e02:2785:b0:433:24d7:309b with SMTP id e9e14a558f8ab-435b9861f13mr9116305ab.14.1763710377994; Thu, 20 Nov 2025 23:32:57 -0800 (PST) MIME-Version: 1.0 References: <04afcd1f-ed7d-4c0a-add1-50e3719ccbf9@postgresfriends.org> <762ae707-7fdc-43d8-a77a-3a10d12ce21d@postgresfriends.org> In-Reply-To: From: Corey Huinker Date: Fri, 21 Nov 2025 02:32:45 -0500 X-Gm-Features: AWmQ_bmEfyyaXqhYZ9YrF37joUFwfLrQCzc2q2WAW4-l2g_zYXTCdvN2_nhy7RQ Message-ID: Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions To: jian he Cc: Vik Fearing , Isaac Morland , pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000912e88064415d2c9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000912e88064415d2c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2025 at 11:36=E2=80=AFPM Corey Huinker wrote: > As mentioned before, to make >> CAST(source_expr AS target_type DEFAULT expr ON CONVERSION ERROR); >> work, >> we cannot just simply replace casting FuncExpr nodes with CoerceViaIO, >> since >> type modifiers behave differently in these two Nodes. >> (e.g., casting numeric 1.11 to integer is not equivalent to casting the >> literal >> "1.11" to integer). >> > > I wasn't suggesting that. I was suggesting that we move tests that use a > given type's custom cast function into the same patch that makes that cas= t > safe. This would mean that the initial syntax+nodes+executor patch starts > out only with test cases known to not have custom functions. > With a second look at the patches, I think the organization is fine as-is. >> Also, are we settled on this new pg_cast column name >> (pg_cast.casterrorsafe)? >> Overall, I think it's better not to touch pg_cast.dat in each of these >> refactoring patches. >> > > I'm fine with it. I can see having 'f' and 's' both mean cast functions, > but 's' means safe, but the extra boolean works too and we'll be fine wit= h > either method. > I can work on this part if you don't have time. > I'll get to reviewing this patchset soon. > Not as soon as I would have liked, but the patchset still applies without error, and survives all of my attempts to break it, including user defined functions that generate errors deterministically as well as non-deterministically, hoping to see it incorrectly use the default rather than reporting the error. --000000000000912e88064415d2c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2025 at 11:36=E2=80=AFPM Core= y Huinker <corey.huinker@gmai= l.com> wrote:
As mentioned before, to make
CAST(source_expr AS target_type DEFAULT expr ON CONVERSION ERROR);
work,
we cannot just simply replace casting FuncExpr nodes with CoerceViaIO, sinc= e
type modifiers behave differently in these two Nodes.
(e.g., casting numeric 1.11 to integer is not equivalent to casting the lit= eral
"1.11" to integer).

I wasn= 9;t suggesting that. I was suggesting that we move tests that use a given t= ype's=C2=A0custom cast function into the same patch that makes that cas= t safe. This would mean that the initial syntax+nodes+executor patch starts= out only with test cases known to not have custom functions.

With a second look at the patches, I t= hink the organization is fine as-is.


Also, are we settled on this new pg_cast column name (pg_cast.casterrorsafe= )?
Overall, I think it's better not to touch pg_cast.dat in each of these<= br> refactoring patches.

I'm fine with = it. I can see having 'f' and 's' both mean cast functions, = but 's' means safe, but the extra boolean works too and we'll b= e fine with either method.

I can work on this part if you don't have time.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

I'll get to reviewing this patchs= et soon.

Not as soon as I= would have liked, but the patchset still applies without error, and surviv= es all of my attempts to break it, including=C2=A0user defined functions th= at generate errors deterministically as well as non-deterministically, hopi= ng to see it incorrectly use the default rather than reporting the error.
--000000000000912e88064415d2c9--