Re: Error-safe user functions

On 2022-12-04 Su 10:25, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 2022-12-03 Sa 16:46, Tom Lane wrote:
>>> 1. Bikeshedding on my name choices is welcome.  I know Robert is
>>> dissatisfied with "ereturn", but I'm content with that so I didn't
>>> change it here.
>> details_please seems more informal than our usual style. details_wanted
>> maybe?
> Yeah, Corey didn't like that either.  "details_wanted" works for me.
>
>> Soon after we get this done I think we'll find we need to extend this to
>> non-input functions. But that can wait a short while.
> I'm curious to know exactly which other use-cases you foresee.
> It wouldn't be a bad idea to write some draft code to verify
> that this mechanism will work conveniently for them.


The SQL/JSON patches at [1] included fixes for some numeric and datetime
conversion functions as well as various input functions, so that's a
fairly immediate need. More generally, I can see uses for error free
casts, something like, say CAST(foo AS bar ON ERROR blurfl)


cheers


andrew


[1]
https://www.postgresql.org/message-id/f54ebd2b-0e67-d1c6-4ff7-5d732492d1a0%40postgrespro.ru

--
Andrew Dunstan
EDB: https://www.enterprisedb.com