Re: Error-safe user functions

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
>> As I said, I'll take a look at the datetime area. Do we
>> have any volunteers for other input functions?

> I am currently looking at the json types. I think that will be enough to
> let us rework the sql/json patches as discussed a couple of months ago.

Cool. I've finished up what I wanted to do with the datetime code.

It occurred to me that we're going to have a bit of a problem
with domain_in. We can certainly make it pass back any soft
errors from the underlying type's input function, and we can
make it return a soft error if a domain constraint evaluates
to false. However, what happens if some function in a check
constraint throws an error? Our only hope of trapping that,
given that it's a general user-defined expression, would be
a subtransaction. Which is exactly what we don't want here.

I think though that it might be okay to just define this as
Not Our Problem. Although we don't seem to try to enforce it,
non-immutable domain check constraints are strongly deprecated
(the CREATE DOMAIN man page says that we assume immutability).
And not throwing errors is something that we usually consider
should ride along with immutability. So I think it might be
okay to say "if you want soft error treatment for a domain,
make sure its check constraints don't throw errors".

Thoughts?

regards, tom lane