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