On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > So, jsonpath behaves like 1000000 is not greater than 2020. This > looks like plain false. And user can't expect that unless she is > familiar with our particular issues. Now I got opinion that such > errors shouldn't be suppressed. We can't suppress *every* error. If > trying to do this, we can come to an idea to suppress OOM error and > return garbage then, which is obviously ridiculous. Opinions?
I don't know enough about jsonpath to have a view on specifically which errors ought to be suppressed, but I agree that it's probably not all of them. In fact, I'd go so far as to say that thinking about it in terms of error suppression is probably not the right approach in the first place. Rather, you want to ask what behavior you're trying to create. For example, if I'm trying to write a function that takes a string as input and returns JSON, where the result is formatted as a number if possible or a string otherwise, I might want access at the C level to the guts of numeric_in, with all parsing errors returned rather than thrown. But it would be silly to suppress an out-of-memory condition, because that doesn't help the caller. The caller wants to know whether the thing can be parsed as a number or not, and that has nothing to do with whether we're out of memory, so an out-of-memory error should still be thrown. In this case here, it seems to me that you should similarly start by defining the behavior you're trying to create. Unless that's clearly defined, deciding which errors to suppress may be difficult. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
