| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | Amul Sul <sulamul(at)gmail(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(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: | 2025-12-08 14:58:00 |
| Message-ID: | CACJufxFUFcA26wLZOVdAhs_AV+eyhqOXw6Fbb8GQT-39m-hYvA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 4, 2025 at 8:47 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
>
> Regarding v13-0019 and v13-0020 patches, I have a bunch of comments
> for the code, but I'd like to understand the implemented design first.
> I have some basic questions regarding the commit message and code
> comment, as follows:
>
> "
> We cannot simply prohibit user-defined functions in pg_cast for safe cast
> evaluation because CREATE CAST can also utilize built-in functions. So, to
> completely disallow custom casts created via CREATE CAST used in safe cast
> evaluation, a new field in pg_cast would unfortunately be necessary.
> "
>
> I might not have understood the implementation completely -- can't we
> use fmgr_last_builtin_oid to detect built-in functions?
> --
hi, Amul.
I have removed the pg_cast.casterrorsafe field.
But in the future, to make the below (Examples) CASTs associated with
built-in function
error safe, I think we need pg_cast.casterrorsafe. Otherwise,
how can we know if the pg_cast.castfunc (built-in function) is error
safe or not.
CREATE CAST (interval AS uuid ) WITH FUNCTION uuidv7(interval);
CREATE CAST (jsonb AS text) WITH FUNCTION jsonb_array_element_text(jsonb, int);
CREATE CAST (json AS text) WITH FUNCTION json_array_element_text(json, int);
I’ve added a dedicated function: CoercionErrorSafeCheck, which
checks whether the cast can be evaluated safely. If not, we throw an error.
SELECT CAST('A' AS DATE DEFAULT NULL ON CONVERSION ERROR)
Here, 'A' is an Unknown Const. As mentioned earlier, Unknown Const Node must be
coerced error safe, otherwise, it will raise an error instead of returning NULL.
The coercion of Unknown Const happens inside coerce_to_target_type, which means
part of that function must run in an error safe. coerce_to_target_type is used
widely, adding another parameter to it seems no good, so I introduced
coerce_to_target_type_extended, coerce_type_extend.
CoerceUnknownConstSafe is being removed.
stringTypeDatumSafe, OidInputFunctionCallSafe functions are needed for coercing
Unknown Const to the target type. Refactoring existing function seems not
ideal, so i invented these two functions.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2025-12-08 14:58:59 | Re: SQL Property Graph Queries (SQL/PGQ) |
| Previous Message | Heikki Linnakangas | 2025-12-08 14:56:22 | Re: Tighten up range checks for pg_resetwal arguments |