Re: Error-safe user functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Error-safe user functions
Дата
Msg-id 4009543.1670422833@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Error-safe user functions  (Andrew Dunstan <andrew@dunslane.net>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Allow tests to pass in OpenSSL FIPS mode
Следующее
От: Muhammad Usama
Дата:
Сообщение: Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row