Re: Error-safe user functions
От | Amul Sul |
---|---|
Тема | Re: Error-safe user functions |
Дата | |
Msg-id | CAAJ_b97JdPRqWbdiCOfNNFLpTB0WqBF=Z3rsf5GAO_Y6N6MUYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Error-safe user functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Error-safe user functions
|
Список | pgsql-hackers |
On Thu, Dec 15, 2022 at 9:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Here are some proposed patches for converting range_in and multirange_in. > > 0001 tackles the straightforward part, which is trapping syntax errors > and called-input-function errors. The only thing that I think might > be controversial here is that I chose to change the signatures of > the exposed functions range_serialize and make_range rather than > inventing xxx_safe variants. I think this is all right, because > AFAIK the only likely reason for extensions to call either of those > is that custom types' canonical functions would need to call > range_serialize --- and those will need to be touched anyway, > see 0002. > > What 0001 does not cover is trapping errors occurring in range > canonicalize functions. I'd first thought maybe doing that wasn't > worth the trouble, but it's not really very hard to fix the built-in > canonicalize functions, as shown in 0002. Probably extensions would > not find it much harder, and in any case they're not really required > to make their errors soft. > > Any objections? > There are other a bunch of hard errors from get_multirange_io_data(), get_range_io_data() and its subroutine can hit, shouldn't we care about those? Regards, Amul
В списке pgsql-hackers по дате отправления: