| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | assam258(at)gmail(dot)com, peter(at)eisentraut(dot)org, vik(at)postgresfriends(dot)org, sulamul(at)gmail(dot)com, reshkekirill(at)gmail(dot)com, 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: | 2026-07-27 21:07:32 |
| Message-ID: | CADkLM=fu2TSd3DjDVC4EvfVXaz9o4f3GsCQh7+VrhhYF2F0PWw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> Please check the rebased v32. Minor changes made in v32:
I'm cautiously optimistic about the 0002 patch. It adds the capability that
we need from cast functions without imposing any load on the executor -
fortunately context already dictates whether a function is called with an
error context or not. It also guarantees that custom types are not presumed
to be cast-safe until their author explicitly declares them so.
To that end, I think there will be considerable debate about how we
describe and document this new attribute. Our choice of function names
ending in -Safe and our keyword choice can give the reader the impression
that the function cannot fail under any circumstances, and we need to be
clear that what we mean is that the function is capable of generating soft
errors of some sort, presumably related to the inputs to the function, but
does not guarantee that all possible errors are caught and captured in the
error context. So far, we've been comfortable calling such a situation
"safe", but this exposes that shorthand to a larger audience and we should
be proactive in dispelling the confusion before it starts.
The usage and testing of in 0003 seems adequate.
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | surya poondla | 2026-07-27 20:46:47 | Re: [DESIGN] Soft DROP TABLE, recoverable drops for PostgreSQL |