On Sat, Aug 25, 2018 at 8:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> There's a backwards-compatibility argument for not changing this behavior, > sure, but I don't buy the other arguments you made here. And I don't > think there's all that much to the backwards-compatibility argument, > considering that the current behavior is to fail. > +1; any code using these functions can reasonably be expected to handle true and false responses. Converting a present error into a false under that presumption results in similar, and arguably improved, semantics. While null is something to be avoided generally this is one of those cases where if we did want to have a "cannot answer the question because pre-conditions are not met" response I'd strongly consider using null to represent that response instead of an error - using coalesce is considerably easier than performing error handling. That isn't an option here and the while there is information loss involved in the proposed change its seems worth it to me to make such a change to make using the function for its primary behavior easier at the cost of a removing a hard-to-use side effect. Adding a new default argument or function is not desirable. To be clear, I do not consider this is not a backpatchable change. David J.
