The Postgres equivalent is https://github.com/ged/ruby-pg/blob/1dd1039983b0f5c15e3cb23e3bf6475dc0b9ee6a/ext/pg_connection.c#L2786

It looks like SQLite has a similar mechanism in https://www.sqlite.org/errlog.html, though that's perhaps too limited for us by being process-global (and, AFAICS, not currently exposed by the gem?)

👋 Hi folks, thanks for the feedback! We can definitely expand this to include PG support -- I couldn't for the life of me find an equivalent warnings feature in PG when we spun this up, so thanks for linking those docs @matthewd !

What may make sense would be to pass the pool config or something to the callback to it can behave differently if needed or even just include the DB name.

This makes sense to me -- maybe let's start with passing the DB name to the proc for now, unless we see some other use case where having the full pool config would be necessary?

maybe let's start with passing the DB name to the proc for now

You mean connection name? Because the DB name would change between environments.

I think passing a rich object is better than just a name. That is assuming the object is public.

You mean connection name?

Yes, sorry I meant the db config names 🤦‍♀️

I think passing a reach object is better than just a name

Yeah, I guess it makes more sense to pass an object here rather than a magic string with the name 😄 PoolConfig is nodoc'ed though, does that make it private? Should we maybe pass a ActiveRecord::DatabaseConfigurations::HashConfig instead?

👍 to pass ActiveRecord::DatabaseConfigurations::DatabaseConfig.

Still need to implement Postgres support, feel free to hold off on reviewing until that's up. I'll re-request reviews when it's ready 😄

I talked about this with Adrianna today and if there are no strong objections I think we should implement this for application level only in this PR and in a followup PR figure out how we want to do it per-connection (either waiting until someone needs / requests it or ensuring it gets in the next release).

figure out how we want to do it per-connection

Wasn't the idea that you could filter that from the callback using the connection that is passed as argument?

Even in multi-db scenarios, 99% of the time you won't have different handling for different DBs. It's nice that you can do it, but I see no need to streamline it more than it already is.

Wasn't the idea that you could filter that from the callback using the connection that is passed as argument?

@eileencodes and I discussed reverting back to the original API and foregoing passing a second argument to the callback (either a connection / db config) until we were more convinced of a per-connection use case. In other words, db_warnings_action can be a proc that takes a single SqlWarning object, and db_warnings_ignore remains a list of Strings / regexps to match against. We felt that the API being discussed didn't seem like quite the right fit (ignoring warnings across an entire db via emit_db_warnings vs a proc for db_warnings_action that receives two arguments vs a proc for db_warnings_ignore that should only receive the SqlWarning itself so as not to be redundant... It felt like there was a lot of overlap within the API).

If we're concerned about the use case Matthew presented (which seems the most viable) of ignoring warnings on secondary databases, we could introduce an ignore_db_warnings config at the database level that "wins out" over the global config. But even that could be delayed until we're more convinced that it's necessary?

Fine by me.

Appreciate the feedback, folks ❤️ I've gone back to individual commits to make this a bit easier to review, I'l squash again when this is ready.

@matthewd @jhawthorn if you don't have any other concerns I'd like to merge this.

Was wondering if we should consider adding an API on top of this one to override the behavior per block. Similar to PedantMysql2.capture_warnings. Doesn't have to be a part of this PR though.

I can imagine someone wanting to perform a query despite of warnings but without adding the warning to the ignore list so they could rescue it like:

   def update_record(params)
       ActiveRecord::Base.connection.execute("query...")
   rescue SQLWarning => e
       # no-op
       # I know my manual query issues a warning but I'm okay with that
       # however I don't want to add the warning to the ignore list as this is the only place which I expect to raise a warning. Every other part of the app should still raise
   end

But this example won't work for a read query as we don't get to use the result if we raise.
And with a wrapper-like API we will be able to do:

   def update_record(params)
     warnings = ActiveRecord.capture_warnings do
        # we know this query issues warnings but this is a specific use-case so we want to ignore it but only here
        result = ActiveRecord::Base.connection.execute("query...")
     end
   end

Was wondering if we should consider adding an API on top of this one to override the behavior per block

I think this is a valid use case for sure 👍 This PR was meant to introduce warning reporting as a simple AR config to start, paving the way for more complex use cases later on. I think introducing #capture_warnings makes sense, but there are implications for thread safety there, so I definitely think we'd want to tackle this in a separate PR.