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 1w0tgT-002Iqe-2u for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Mar 2026 03:59:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0tgS-001fip-16 for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Mar 2026 03:59:32 +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 1w0tgR-001fig-31 for pgsql-hackers@lists.postgresql.org; Fri, 13 Mar 2026 03:59:32 +0000 Received: from mail-dl1-x1234.google.com ([2607:f8b0:4864:20::1234]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w0tgQ-00000001sgW-1chC for pgsql-hackers@lists.postgresql.org; Fri, 13 Mar 2026 03:59:31 +0000 Received: by mail-dl1-x1234.google.com with SMTP id a92af1059eb24-1271195d2a7so1437599c88.0 for ; Thu, 12 Mar 2026 20:59:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773374370; cv=none; d=google.com; s=arc-20240605; b=grfmkFFXqI1/LIra/EkZnjtyeVbT9qC6cJE23tDdVuMQJC3IH8Nyke78/JjmXgjxwT xJN+XcEU0A4+m3+3265I1b8FNer31XBnQAgwdwUWWl+eOgtQr766ZgyNv7IacFfOZrCn IgJ7WT4DmzrZH+4iz/MzsPH23GkAfR/47sp6Ife6kelmOnBpT3yoMvxI/ZbikYM0+RL3 AhJkvJtpyYI22K+DfV2e+yXU4tLDTSf9WPfjZk0UbJfKe90gwF2p1kw3g6qunhXL/IYN 9hpATuMWzirpvXAhQZjDCIR8YuvnW6Wh8eEFu9c5IZQGBPhzfqzNDsHf9E9e96vK38JE pFGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=GjlhOVL6DCDVBLNUiv+nrn8+b3Z4Bv6zLGbx0JQHl2Q=; fh=E8cQg97zgp6Bg2M8wTmGFPzINeRxRAwzRB6w3moQg74=; b=dYQNCR20tasB63bEh99q65p9WIYpZ2BWSklThNuTm2ohWJUHelotYoqY9RnDVtsgCo ErYHJ5B+Y7onxuWVCJfCeAVDsHHTOFG9k8ZC04IdTQGLjecERModL+k915tkK+tZYJBO z3QEDIzu1Om5ivMtwHwW9n+ozCMuNJ2liy5uM+9KYgWdsEX8ujyArCJBCh1X2RIcxt5u 4JsfVNiN0YKmh7c9mWS2RQDinwb/H5AvtY93ufWYWpUHfDOre3HCEOfszVhx5SaTGSJN oN0EnS8TkCvUQJAoAZSLvQKrpSSyIDp64wAVEh090AKlH6j4UnayZL7M4DTZNf2r28za 7kSw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773374370; x=1773979170; 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=GjlhOVL6DCDVBLNUiv+nrn8+b3Z4Bv6zLGbx0JQHl2Q=; b=h7IfwM30v6rzdZjVlNJL/yRHhlOLkNgnrHGA9W0N+ozfRZnB+gGuwfF33GFHrLyEau Pi2WUgFMpYl0tMz/62LTZ7te82czEpXHqoY6qhmt5s0HovHWBRfY6ZTKw9UUGlOSHZ3r AJsRZr3/cU3TAMDnimKm4d0xz9JyGrL6z2XG1eoX8VHcoufAbOblBDmsegAd6YTXd0LL uP2rhXrxrWebaQZaE0Fj9dtCheowdmVmtakGGYR/a0JaGuDG2iiSifh3P+GqZu50oSDz JcJxiZQ9U69cH7je3bGJ9iO8Ybfb7asSVKuhjcfbxVVrFwlBGKlF8IrdkM22vgwjr96m vNQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773374370; x=1773979170; 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=GjlhOVL6DCDVBLNUiv+nrn8+b3Z4Bv6zLGbx0JQHl2Q=; b=loUakfmG198V1Eo+0j96PH5YFsrfVZqyyJEltNuuPHZ4l1WunJjqBEg1SL7UkebgBl LmLf7tP1bjJiWXDyZzE+EXjmLPDE1OG1ayXI2/gVmsH5wsX7cn1grRI6m2Vq+aVe4Yd5 qD8u/4OVUNpSVi/vpEPgbnN4hmD+YeqPzLt6RzqwPZ2AAdfLo/6xDM3S1d5pszrFS8xn rAceshplJLj5qQc09G9sm4WExTV+eLuxlflP/NsvphgeR+LLGYtnKwMArpXSfJehCmpK XClakjFbvOFGGA5Dqy/dWfZicSfJjCxyJ6dAaidu8PtS59e9AaUgqILfkPtDp06NECZE l43w== X-Forwarded-Encrypted: i=1; AJvYcCW4pKvLFBs7oRtFlAbB9R1hwt35hGK/4/DkTuNbXuCXonig6sqS3RGNpmfut0IEmwss9a27IN4eMwhJwk5C@lists.postgresql.org X-Gm-Message-State: AOJu0YytTtvcdi++WCrfJ1mwH+Ia3tJ8omCuNMYuCwQTBtVO4oMhbUyI cWjXmJ3yXKWd6PZ7rHxIJGBB4GQowkD9gmCp32oh3H3MYZKSotgFy4CRixC0LVppEQ4pRrc+j88 E7cmk0fFK6Ik8Dw6Nktj5YrgbpG+siRE= X-Gm-Gg: ATEYQzyAEih8u4RNc8BERk4aGURWt8wST2fIWO44+99ihL++2Jc6aqp2uPOVK9ZsKfm H+AYotk6prn2pdk4iFDERq0wWzwX83bvM1v1sJB6H7unHtM3LRZ4MVTC8sQyYjGF427hp2Gsnkz n3r5V+WoXPk4b131CEefzTM2XpR28azx9feRhBylVuiC3iGSgKu70yV7qjvnCl/xJ8dn8c5eyvP bzX1vJXmZlI8lEp2stzPI4KaOCUyVSKBbt6ZoyE3dfXy0Ln2mtocq7LAL9fMDImc+NQMP/4K32O eIXqjkYKXOBmwk4wUpeeitJmuGhPGoR/aKVqfPVbU17AJ8gqnFovxrY5oEcCWdf+r9PWqlKTay4 dh4xlkCFNuWZuEHWsnWMniQ57 X-Received: by 2002:a05:7022:2508:b0:127:5cfd:785 with SMTP id a92af1059eb24-128f3d1aa4fmr850454c88.4.1773374369526; Thu, 12 Mar 2026 20:59:29 -0700 (PDT) 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: Thu, 12 Mar 2026 23:59:17 -0400 X-Gm-Features: AaiRm515ZoXacoLE_ZCRAZ3rUGzDZb1AEnnfGqbxdOeCVW2MxTSb5_VB-Ck6DBw Message-ID: Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions To: jian he Cc: Amul Sul , Kirill Reshke , Vik Fearing , Isaac Morland , pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000597a30064cdfe563" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000597a30064cdfe563 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 12, 2026 at 9:00=E2=80=AFPM jian he wrote: > On Wed, Mar 11, 2026 at 12:22=E2=80=AFAM Corey Huinker > wrote: > > > > While I still think the patch order is a bit backwards [1], the order > chosen does have a sense to it, and whether or not that is the right orde= r > is up to the committer. Please post a rebase so I can mark it as ready fo= r > committer. > > > > > > [1] I would have preferred adding the CAST functionality first, then > switching over each datatype one-by-one, thus demonstrating that non-safe > datatypes can co-exist with this new functionality. But that's just my > personal preference. > > We can evaluate CoerceViaIO in an error-safe manner in the HEAD. > However, as discussed in this thread[1], we cannot simply take a FuncExpr > produced by a TYPE CAST, convert it to a CoerceViaIO node, and rely on > CoerceViaIO to do the actual soft-error evaluation. > Therefore to support the CAST(expr AS newtype DEFAULT expr ON CONVERSION > ERROR) > syntax, refactoring the existing cast functions to make them error-safe i= s > really necessary. > Overall I think refactoring the existing cast function (replacing > ereport to ereturn or errsave) should be done first. > > I did one more round of comment refactoring and variable renaming. > Can you explain this bit below? @@ -595,13 +605,23 @@ RangeVarGetRelidExtended(const RangeVar *relation, LOCKMODE lockmode, { int elevel =3D (flags & RVR_SKIP_LOCKED) ? DEBUG1 : ERROR; - if (relation->schemaname) - ereport(elevel, + if (relation->schemaname && elevel =3D=3D DEBUG1) + ereport(DEBUG1, (errcode(ERRCODE_LOCK_NOT_AVAILABLE), errmsg("could not obtain lock on relation \"%s.%s\"", relation->schemaname, relation->relname))); - else - ereport(elevel, + else if (relation->schemaname && elevel =3D=3D ERROR) + ereturn(escontext, InvalidOid, + errcode(ERRCODE_LOCK_NOT_AVAILABLE), + errmsg("could not obtain lock on relation \"%s.%s\"", + relation->schemaname, relation->relname)); + else if (elevel =3D=3D DEBUG1) + ereport(DEBUG1, + errcode(ERRCODE_LOCK_NOT_AVAILABLE), + errmsg("could not obtain lock on relation \"%s\"", + relation->relname)); + else if (elevel =3D=3D ERROR) + ereturn(escontext, InvalidOid, --000000000000597a30064cdfe563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2026 at 9:00=E2=80=AFPM jian = he <jian.universality@gma= il.com> wrote:
On Wed, Mar 11, 2026 at 12:22=E2=80=AFAM Corey Huinker <corey.huinker@gmail.com<= /a>> wrote:
>
> While I still think the patch order is a bit backwards [1], the order = chosen does have a sense to it, and whether or not that is the right order = is up to the committer. Please post a rebase so I can mark it as ready for = committer.
>
>
> [1] I would have preferred adding the CAST functionality first, then s= witching over each datatype one-by-one, thus demonstrating that non-safe da= tatypes can co-exist with this new functionality. But that's just my pe= rsonal preference.

We can evaluate CoerceViaIO in an error-safe manner in the HEAD.
However, as discussed in this thread[1], we cannot simply take a FuncExpr produced by a TYPE CAST, convert it to a CoerceViaIO node, and rely on
CoerceViaIO to do the actual soft-error evaluation.
Therefore to support the CAST(expr AS newtype DEFAULT expr ON CONVERSION ER= ROR)
syntax, refactoring the existing cast functions to make them error-safe is<= br> really necessary.
Overall I think refactoring the existing cast function (replacing
ereport to ereturn or errsave) should be done first.

I did one more round of comment refactoring and variable renaming.

Can= you explain this bit below?

@@ -595,13 +605,23 @@ RangeVarGetRelidExtended(const Range= Var *relation, LOCKMODE lockmode,
=C2=A0 {
=C2=A0 int elevel =3D= (flags & RVR_SKIP_LOCKED) ? DEBUG1 : ERROR;
=C2=A0
- if (relat= ion->schemaname)
- ereport(elevel,
+ if (relation->scheman= ame && elevel =3D=3D DEBUG1)
+ ereport(DEBUG1,
=C2=A0 = (errcode(ERRCODE_LOCK_NOT_AVAILABLE),
=C2=A0 errmsg("could n= ot obtain lock on relation \"%s.%s\"",
=C2=A0 rela= tion->schemaname, relation->relname)));
- else
- ereport(e= level,
+ else if (relation->schemaname && elevel =3D=3D ERR= OR)
+ ereturn(escontext, InvalidOid,
+ errcode(ERRCODE_LOCK_N= OT_AVAILABLE),
+ errmsg("could not obtain lock on relation \&q= uot;%s.%s\"",
+ =C2=A0 relation->schemaname, relatio= n->relname));
+ else if (elevel =3D=3D DEBUG1)
+ ereport(DEBU= G1,
+ errcode(ERRCODE_LOCK_NOT_AVAILABLE),
+ errmsg("c= ould not obtain lock on relation \"%s\"",
+ =C2=A0= relation->relname));
+ else if (elevel =3D=3D ERROR)
+ eretu= rn(escontext, InvalidOid,

=C2=A0
--000000000000597a30064cdfe563--