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

From Tom Lane
Subject Re: Error-safe user functions
Date
Msg-id 4009543.1670422833@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error-safe user functions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Error-safe user functions  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Error-safe user functions  (Andrew Dunstan <andrew@dunslane.net>)
Re: Error-safe user functions  (Corey Huinker <corey.huinker@gmail.com>)
Re: Error-safe user functions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Perhaps we should add a type in the regress library that will never have
> a safe input function, so we can test that the mechanism works as
> expected in that case even after we adjust all the core data types'
> input functions.

I was intending that the existing "widget" type be that.  0003 already
adds a comment to widget_in saying not to "fix" its one ereport call.

Returning to the naming quagmire -- it occurred to me just now that
it might be helpful to call this style of error reporting "soft"
errors rather than "safe" errors, which'd provide a nice contrast
with "hard" errors thrown by longjmp'ing.  That would lead to naming
all the variant functions XXXSoft not XXXSafe.  There would still
be commentary to the effect that "soft errors must be safe, in the
sense that there's no question whether it's safe to continue
processing the transaction".  Anybody think that'd be an
improvement?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Allow tests to pass in OpenSSL FIPS mode
Next
From: Muhammad Usama
Date:
Subject: Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row