> > > As far as that goes, it shouldn't be that hard to deal with, at least > not for "soft" errors which hopefully cover most input-function > failures these days. You should be invoking array_in via > InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext. > (Look at pg_input_error_info() for useful precedent.) >
Ah, my understanding may be out of date. I was under the impression that that mechanism relied on the the cooperation of the per-element input function, so even if we got all the builtin datatypes to play nice with *Safe(), we were always going to be at risk with a user-defined input function. > There might be something to be said for handling all the error > cases via an ErrorSaveContext and use of ereturn() instead of > ereport(). Not sure if it's worth the trouble or not. > It would help us tailor the user experience. Right now we have several endgames. To recap: 1. NULL input => Return NULL. (because strict). 2. Actual error (permissions, cache lookup not found, etc) => Raise ERROR (thus ruining binary upgrade) 3. Call values are so bad (examples: attname not found, required stat missing) that nothing can recover => WARN, return FALSE. 4. At least one stakind-stat is wonky (impossible for datatype, missing stat pair, wrong type on input parameter), but that's the worst of it => 1 to N WARNs, write stats that do make sense, return TRUE. 5. Hunky-dory. => No warns. Write all stats. return TRUE. Which of those seem like good ereturn candidates to you?
