I wrote: > Amul Sul <sula...@gmail.com> writes: >> Attaching a complete set of the patches changing function till this >> except bpcharin, byteain jsonpath_in that Andrew is planning to look >> in. I have skipped reg* functions.
> I'll take a look at these shortly, unless Andrew is already on it. I've gone through these now and revised/pushed most of them. I do not think that we need to touch any unimplemented I/O functions. They can just as well be unimplemented for soft-error cases too; I can't see any use-case where it could be useful to have them not complain. So I discarded v1-0004-Change-brin_bloom_summary_in-to-allow-non-throw-e.patch v1-0005-Change-brin_minmax_multi_summary_in-to-allow-non-.patch v1-0009-Change-gtsvectorin-to-allow-non-throw-error-repor.patch v1-0018-Change-pg_mcv_list_in-to-allow-non-throw-error-re.patch v1-0019-Change-pg_ndistinct_in-to-allow-non-throw-error-r.patch As for the rest, some were closer to being committable than others. You need to be more careful about handling error cases in subroutines: you can't just ereturn from a subroutine and figure you're done, because the caller will keep plugging along if you don't do something to teach it not to. What that would often lead to is the caller finding what it thinks is a new error condition, and overwriting the original message with something that's much less on-point. This is comparable to cascading errors from a compiler: anybody who's dealt with those knows that errors after the first one are often just noise. So we have to be careful to quit after we log the first error. Also, I ended up ripping out the changes in line_construct, because as soon as I tried to test them I tripped over the fact that lseg_sl was still throwing hard errors, before we ever get to line_construct. Perhaps it is worth fixing all that but I have to deem it very low priority, because the two-input-points formulation isn't the mainstream code path. (I kind of wonder too if there isn't a better, more numerically robust conversion method ...) In any case I'm pretty sure those changes in float.h would have drawn Andres' ire. We don't want to be adding arguments to float_overflow_error/float_underflow_error; if that were acceptable they'd not have looked like that to begin with. Anyway, thanks for the work! That moved us a good ways. I think I'm going to go fix bpcharin and varcharin, because those are the last of the SQL-spec-defined types. regards, tom lane