Horton

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

amul sul <sulamul@gmail.com>

View thread
From: Amul Sul <sulamul@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Vik Fearing <vik@postgresfriends.org>, Isaac Morland <isaac.morland@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-12-01T12:08:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make cast functions to type money error safe

  2. Make cast function from circle to polygon error safe

  3. Make geometry cast functions error safe

  4. Make cast functions from jsonb error safe

  5. Make many cast functions error safe

  6. Add SQL/JSON query functions

  7. Add soft error handling to some expression nodes

On Tue, Nov 25, 2025 at 8:30 AM jian he <jian.universality@gmail.com> wrote:
>
> On Mon, Nov 24, 2025 at 11:38 AM Amul Sul <sulamul@gmail.com> wrote:
> >
> > [...]
> +static inline float8
> +float8_div_safe(const float8 val1, const float8 val2, struct Node *escontext)
>
> but we can change float8_div to:
>
> static inline float8
> float8_div(const float8 val1, const float8 val2)
> {
>    return float8_div_safe(val1, val2, NULL);
> }
> I am worried that entering another function would cause a minor performance
> degradation.  And since these simple functions are so simple, keeping them
> separated should not be a big problem.  also I placed float8_div,
> float8_div_safe together.

Since you declared float8_div_safe() as static inline, I believe it
wouldn't have any performance degradation since most compilers
optimize it. Also, I suggest you pass the ErrorSafeContext to
float_overflow_error(), float_underflow_error(), and
float_zero_divide_error() so that you can avoid duplicating error
messages.

Regards,
Amul