| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions |
| Date: | 2026-03-13 03:59:17 |
| Message-ID: | CADkLM=cZ7N+f4Bj-8MiccFcTASjBB2r1_s3BD9OFbbQOwK01cg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 12, 2026 at 9:00 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> On Wed, Mar 11, 2026 at 12:22 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)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,
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2026-03-13 04:23:29 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |
| Previous Message | jian he | 2026-03-13 03:55:44 | Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT |