Sean Linsley

There are failing tests that call e.g. `where(id: [3, 9223372036854775808])` on a bigint column, using values that are larger than the bigint column can contain. I assume this was relying...

`IN` and `any()` are similar in their behavior, though the performance varies. The ~70% performance boost seen in the benchmark is likely caused by Postgres being faster at parsing parameter...

Hi @andyatkinson, yes this change will collapse the hundreds / thousands of separate PGSS entries into a single one: ```sql select pg_stat_statements_reset(); select count(*) from users where id in (1);...

@simi while it would be great for Postgres to fix this upstream, there have been years of discussions over that (and previous attempts), so it's not guaranteed that patch will...

>I've read through [the function mentioned on the Postgres list](https://github.com/postgres/postgres/blob/77d0ad6c46c518234b9ce0a5be1f61a25f1bf753/src/backend/parser/parse_expr.c#L1104-L1260) that transforms an IN expression to an array expression. My C is limited, but it looks like the cases that...

>While I understand it is important to avoid polluting pg_stat_statements, I am concerned about the potential unforeseen side effects of rewriting all 'in' clauses to 'any' for this purpose. @yahonda...

The PR description and changelog entry have been updated to highlight the benefit to prepared statements. I still intend on adding tests for other data types, but now the code...

This is still waiting on review from Rails maintainers. It could use additional tests for the many Postgres data types supported, but I'm not sure if there is a list...

I'd be happy to help onboard a new maintainer, but I only have access to the github repo. @jcasimir and @codebycliff are the only ones with rubygems access currently.

I'd tend to agree with @robgleeson -- if it's not a true dependency but instead a built-in integration, it shouldn't be in the gemspec.