On Tue, 19 Dec 2023 at 17:12, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Dec 8, 2023 at 1:34 PM Andres Freund <andres@anarazel.de> wrote:
> > Oh, very much agreed. But I suspect we won't quickly do the same for
> > out-of-core extensions...
>
> I feel like this is a problem that will sort itself out just fine. The
> rules about using ereport() and elog() could probably be better
> documented than they are, but doing that won't cause people to follow
> the practices any more rigorously than they have been. However, a
> change like this just might. If we make this policy change in core,
> then extension authors will probably get pressure from users to clean
> up any calls that are emitting excessively verbose log output, and
> that seems like a good thing.
As an extension author I wanted to make clear that Andres his concern
is definitely not theoretical. Citus (as well as most other extensions
me and our team at Microsoft maintains) use ereport without an error
code very often. And while we try to use elog actually only for
internal errors, there's definitely places where we haven't.
We've had "adding error codes to all our errors" on our backlog for
years though. I'm guessing this is mostly a combination of it being a
boring task, it being a lot of work, and the impact not being
particularly huge (i.e. now users can check error codes for all our
errors wohoo!). If ereport without an errorcode would suddenly cause a
log flood in the next postgres release then suddenly the impact of
adding error codes would increase drastically. And as Robert said we'd
basically be forced to adopt the pattern. Which I agree isn't
necessarily a bad thing.
But I'm not sure that smaller extensions that are not maintained by a
team that's paid to do so would be happy about this change. Also I
think we'd even change our extension to add errror codes to all
ereport calls if the stack traces are useful enough, because then the
impact of adding error codes suddenly increases a lot. So I think
having a way for extensions to opt-in/opt-out of this change for their
extension would be very much appreciated by those authors.
