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

From jian he
Subject Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Date
Msg-id CACJufxFjPnEv__85qfFh9c21Q7nx7dAnymcnq5tECJofTTzG7g@mail.gmail.com
Whole thread Raw
In response to Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions  (Amul Sul <sulamul@gmail.com>)
List pgsql-hackers
On Mon, Nov 17, 2025 at 9:43 PM Amul Sul <sulamul@gmail.com> wrote:
>
> 10-0004:
>
> +/* error safe version of textToQualifiedNameList */
> +List *
> +textToQualifiedNameListSafe(text *textval, Node *escontext)
>
> If I am not mistaken, it looks like an exact copy of
> textToQualifiedNameList(). I think you can simply keep only
> textToQualifiedNameListSafe() and call that from
> textToQualifiedNameList() with a NULL value for escontext. This way,
> all errsave() or ereturn() calls will behave like ereport().
>
> The same logic applies to RangeVarGetRelidExtendedSafe() and
> makeRangeVarFromNameListSafe. These can be called from
> RangeVarGetRelidExtended() and makeRangeVarFromNameList(),
> respectively.
> --
>

hi.

List *
textToQualifiedNameList(text *textval)
{
    List       *namelist;
    rawname = text_to_cstring(textval);
    if (!SplitIdentifierString(rawname, '.', &namelist))
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_NAME),
                 errmsg("invalid name syntax")));
}

I don’t see any way to pass the escontext (ErrorSaveContext) without changing
the textToQualifiedNameList function signature.

There are around 30 occurrences of textToQualifiedNameList.
changing the function textToQualifiedNameList signature is invasive,
so I tend to avoid it.
I think it's easier to just duplicate textToQualifiedNameList
than changing the function textToQualifiedNameList signature.

Am I missing something?

--
jian
https://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: * Neustradamus *
Date:
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support
Next
From: Heikki Linnakangas
Date:
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support