| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(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-10 13:32:06 |
| Message-ID: | CALdSSPjd2fJHw8TrugumZSQwJ8VmSVn55OfQ+Wuogaq0ss=HGQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 10 Dec 2025 at 13:58, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> On Tue, Dec 9, 2025 at 11:39 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> >
> > On Mon, Dec 1, 2025 at 1:41 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
> > >>
> > > No, I meant implementing the syntax for being able to declare a custom CAST function as safe (or not). Basically adding the [SAFE] to
> > >
> > > CREATE CAST (source_type AS target_type)
> > > WITH [SAFE] FUNCTION function_name [ (argument_type [, ...]) ]
> > >
> > > I'm not tied to this syntax choice, but this one seemed the most obvious and least invasive.
> > >
>
> hi.
> please see the attached v15.
> the primary implementation of CAST DEFAULT is contained in V15-0021.
>
> changes compared to v14.
> 1. separate patch (v15-0017) for float error.
> -pg_noreturn extern void float_overflow_error(void);
> -pg_noreturn extern void float_underflow_error(void);
> -pg_noreturn extern void float_zero_divide_error(void);
> +extern void float_overflow_error(struct Node *escontext);
> +extern void float_underflow_error(struct Node *escontext);
> +extern void float_zero_divide_error(struct Node *escontext);
>
> 2. separate patch (v15-0018) for newly added float8 functions:
> float8_pl_safe
> float8_mi_safe
> float8_mul_safe
> float8_div_safe
> refactoring existing functions is too invasive, I choose not to.
>
> 3. refactor point_dt (v15-0019). This is necessary for making geometry data type
> error-safe, separate from the main patch (v15-0020). I hope to make it easier to
> review.
> -static inline float8 point_dt(Point *pt1, Point *pt2);
> +static inline float8 point_dt(Point *pt1, Point *pt2, Node *escontext);
>
> 4. skip compile DEFAULT expression (ExecInitExprRec) for binary coercion cast,
> as mentioned before. See ExecInitSafeTypeCastExpr.
>
> 5. Support user-defined type cast error-safe, see v15-0022.
> user-defined error-safe cast syntax:
> CREATE CAST (source_type AS target_type)
> WITH [SAFE] FUNCTION function_name [ (argument_type [, ...]) ]
> [ AS ASSIGNMENT | AS IMPLICIT ]
>
> this only adds a new keyword SAFE.
> This works for C and internal language functions only now.
> To make it really usable, I have made citext, hstore module castfunc error safe.
> A new column: pg_cast.casterrorsafe was added, this is needed for
> CREATE CAST WITH SAFE FUNCTION.
>
> +select CAST(ARRAY['a','g','b','h',null,'i'] AS hstore
> + DEFAULT NULL ON CONVERSION ERROR);
> + array
> +-------
> +
> +(1 row)
> +
>
> 6. slightly polished the doc.
>
>
> --
> jian
> https://www.enterprisedb.com/
Hi!
Overall, I think this patch is doing a good thing. Also, are we
holding it until the next SQL standard release, because sql/23 leaks
this feature?
Below are my 2c.
1)
First of all, I would prefer the `Bumps catversion` comment in the
commit msg of v15-0022.
2)
In v15-0006, if dont understand when memory allocated by
`result = (macaddr *) palloc0(sizeof(macaddr));` will be freed. Does
it persist until the query ends? I tried to get OOM with a query that
errors out macaddr8 casts repeatedly, but failed.
3)
> * When error_safe set to true, we will evaluate the constant expression in a
> * error safe way. If the evaluation fails, return NULL instead of throwing
> * error.
Somebody has to say it - s/error_safe set/error_safe is set/, also
s/throwing error/throwing an error/
--
Best regards,
Kirill Reshke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-12-10 13:33:11 | Re: pg_plan_advice |
| Previous Message | Chao Li | 2025-12-10 13:30:02 | Re: Improve comment in function GetPublicationRelations |