feat: add native_in/2 function for SQL IN (...) syntax

[jkreddy020203]

Summary

• Adds AshPostgres.Functions.NativeIn as an escape hatch for cases where PostgreSQL's query planner produces suboptimal plans with = ANY(...) array syntax
• The native_in/2 function generates IN ($1, $2, ...) with individually typed parameters instead of = ANY($1::type[])
• Values are properly typed based on the left-hand field's Ecto type (e.g., UUID fields encode correctly)

Usage

Post
|> Ash.Query.filter(native_in(id, [^id1, ^id2, ^id3]))
|> Ash.read!()

Generates:

WHERE id IN ($1, $2, $3)

Instead of:

WHERE id = ANY($1::uuid[])

Context

Closes ash-project/ash#2605

PostgreSQL's query planner may choose different (sometimes suboptimal) indexes when using = ANY('{...}'::type[]) compared to IN ($1, $2, ...). This was reported as a significant performance issue on PostgreSQL 14. As suggested by @zachdaniel, this provides a function-based escape hatch rather than changing the default behavior.

Changes

• lib/functions/native_in.ex — Function definition ([:any, {:array, :any}] args)
• lib/sql_implementation.ex — Expression handler that builds a SQL fragment with expanded parameters
• lib/data_layer.ex — Register the function
• test/native_in_test.exs — Tests for SQL generation and functional correctness

Test plan

• Verifies generated SQL uses IN (...) not ANY(...)
• Returns correct matching records
• Returns empty list when no values match
• Works with a single value
• Full test suite passes with 0 regressions

[zachdaniel]

WDYT about postgres_in? Makes it more clear what it maps to IMO.

[zachdaniel]

🚀 Thank you for your contribution! 🚀