Hi, On 2019-07-17 22:59:01 +0000, Fabien COELHO wrote: > > > > with an interface inconsistent with its int32/int16 relatives now only > > > > in the backend. > > > > > > We can, but I'm not at ease with changing the error handling approach. > > > > Why? > > If a function reports an error to log, it should keep on doing it, otherwise > there would be a regression.
Err, huh. Especially if we change the signature, I fail to see how it's a regression if we change the behaviour. > > > Another higher-level one which possibly adds an error message (stderr for > > > front-end, log for back-end). > > > > Is there actually any need for a non-backend one that has an > > error-message? > > Pgbench uses it. If the function is shared and one is loging something, it > looks ok to send to stderr for front-end? > > I'm not convinced that in the frontend it's very useful to have such a > > function that exits - in the backend we have a much more complete way to > > handle that, including pointing to the right location in the query > > strings etc. > > Sure. There is not exit though, just messages to stderr and return false. I think it's a seriously bad idea to have a function that returns depending in the error case depending on whether it's frontend or backend code. We shouldn't do stuff like that, it just leads to bugs. > > > One choice is whether there are two functions (the higher one calling the > > > lower one and adding the messages) or just one with a boolean to trigger > > > the > > > messages. I do not have a strong opinion. Maybe one function would be > > > simpler. Andres boolean-compatible enum return looks like a good option. > > > > The boolean makes the calling code harder to understand, the function > > slower, > > Hmmm. So I understand that you would prefer 2 functions, one raw (fast) one > and the other with the other with the better error reporting facity, and the > user must chose the one they like. I'm fine with that as well. Well, the one with error reporting would use the former. Greetings, Andres Freund
