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

From Andrew Dunstan
Subject Re: Error-safe user functions
Date
Msg-id 40ff1ed1-4245-e343-bffa-c7755b031492@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-05 Mo 20:06, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>
>> But perhaps it's even worth having such a function properly exposed:
>> It's not at all rare to parse text data during ETL and quite often
>> erroring out fatally is undesirable. As savepoints are undesirable
>> overhead-wise, there's a lot of SQL out there that tries to do a
>> pre-check about whether some text could be cast to some other data
>> type. A function that'd try to cast input to a certain type without
>> erroring out hard would be quite useful for that.
> Corey and Vik are already talking about a non-error CAST variant.


/metoo! :-)


> Maybe we should leave this in abeyance until something shows up
> for that?  Otherwise we'll be making a nonstandard API for what
> will probably ultimately be SQL-spec functionality.  I don't mind
> that as regression-test infrastructure, but I'm a bit less excited
> about exposing it as a user feature.
>             


I think a functional mechanism could be very useful. Who knows when the
standard might specify something in this area?


cheers


andrew

-- 

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




pgsql-hackers by date:

Previous
From: Sravan Kumar
Date:
Subject: Re: Question regarding "Make archiver process an auxiliary process. commit"
Next
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE