On Thu, Dec 15, 2022 at 9:03 AM Tom Lane <t...@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
