Re: Error-safe user functions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Error-safe user functions
Date
Msg-id 4fb63750-6925-d444-b855-17927bd72bc4@dunslane.net
Whole thread Raw
In response to Re: Error-safe user functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error-safe user functions
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Add .idea to gitignore for JetBrains CLion
Next
From: Vik Fearing
Date:
Subject: Re: Questions regarding distinct operation implementation