Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Date
Msg-id CADkLM=cZ7N+f4Bj-8MiccFcTASjBB2r1_s3BD9OFbbQOwK01cg@mail.gmail.com
Whole thread Raw
In response to Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions  (jian he <jian.universality@gmail.com>)
Responses Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
List pgsql-hackers
On Thu, Mar 12, 2026 at 9:00 PM jian he <jian.universality@gmail.com> wrote:
On Wed, Mar 11, 2026 at 12:22 AM Corey Huinker <corey.huinker@gmail.com> 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 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 is
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 = (flags & RVR_SKIP_LOCKED) ? DEBUG1 : ERROR;
 
- if (relation->schemaname)
- ereport(elevel,
+ if (relation->schemaname && elevel == 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 == 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 == DEBUG1)
+ ereport(DEBUG1,
+ errcode(ERRCODE_LOCK_NOT_AVAILABLE),
+ errmsg("could not obtain lock on relation \"%s\"",
+   relation->relname));
+ else if (elevel == ERROR)
+ ereturn(escontext, InvalidOid,

 

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT
Next
From: shveta malik
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication