Re: Error-safe user functions
| От | Ted Yu |
|---|---|
| Тема | Re: Error-safe user functions |
| Дата | |
| Msg-id | CALte62yRJwVzp5CxRRsumXV-0Y1JBHZguRGFMQt2fgwH0nUusw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Error-safe user functions (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Error-safe user functions
Re: Error-safe user functions |
| Список | pgsql-hackers |
On Fri, Dec 23, 2022 at 1:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ted Yu <yuzhihong@gmail.com> writes:
> In makeItemLikeRegex :
> + /* See regexp.c for explanation */
> + CHECK_FOR_INTERRUPTS();
> + pg_regerror(re_result, &re_tmp, errMsg,
> sizeof(errMsg));
> + ereturn(escontext, false,
> Since an error is returned, I wonder if the `CHECK_FOR_INTERRUPTS` call is
> still necessary.
Yes, it is. We don't want a query-cancel transformed into a soft error.
regards, tom lane
Hi,
For this case (`invalid regular expression`), the potential user interruption is one reason for stopping execution.
I feel surfacing user interruption somehow masks the underlying error.
The same regex, without user interruption, would exhibit an `invalid regular expression` error.
I think it would be better to surface the error.
Cheers
В списке pgsql-hackers по дате отправления: