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

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: 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-08-05 04:10:33
Message-ID: CADkLM=chahh6ddZFjLL6AUdqzL_Px0raTu-5Jzn2WN8yELtmJw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> In the end, it seems we need to make all these functions in the below
> query error safe.
> select castsource::regtype, casttarget::regtype, castfunc,
> castcontext,castmethod, pp.prosrc, pp.proname from pg_cast pc join pg_proc
> pp on
> pp.oid = pc.castfunc and pc.castfunc > 0
> order by castsource::regtype;
> It's a lot of work, but seems doable, after playing around with it.
>

It is do-able. But that's just the cast functions that are part of core
postgres.

>
>
> I don't think we need to change the pg_cast catalog entry,
> we just need to make these function (pg_cast.castmethod) errors safe.

That would break any user-defined cast functions that were not also error
safe, which is to say all of them.

We need a way for user-defined cast functions to indicate whether or not
they are error safe, and handle both situations accordingly (i.e. fail a
CAST ON DEFAULT when the user-defined cast is not error-safe).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-08-05 04:20:09 Re: Dropping publication breaks logical replication
Previous Message shveta malik 2025-08-05 03:58:27 Re: Improve pg_sync_replication_slots() to wait for primary to advance