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).
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 |