comparing against range_lower raises on ash_postgres

[matt-beanland]

Code of Conduct

• I agree to follow this project's Code of Conduct

AI Policy

• I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

Versions

Elixir 1.20.2
Erlang/OTP 29 (erts-17.0.3)
ash main @ f3a27d9 (unreleased; mix.exs still says 3.31.3)

Operating system

macOS 26.5.2 (Darwin 25.5.0) aarch64

Current Behavior

range_lower(stay) == ^datetime raises on ash_postgres, and works on Ash.DataLayer.Ets.

Reproduction

in iex:

Mix.install([{:ash, github: "ash-project/ash", ref: "f3a27d9f5"}])

{:ok, c} = Ash.Type.init(Ash.Type.Range, inner_type: :datetime)

ref = %Ash.Query.Ref{
  attribute: %Ash.Resource.Attribute{name: :stay, type: Ash.Type.Range, constraints: c},
  relationship_path: [],
  resource: nil
}

Ash.Expr.determine_types(
  Ash.Query.Operator.Eq,
  [%Ash.Query.Function.RangeLower{arguments: [ref]}, ~U[2026-03-01 00:00:00Z]]
)
#=> {[{Ash.Type.Range, [...]}, {Ash.Type.Range, [...]}], {Ash.Type.Boolean, []}}

Both operands come back as Ash.Type.Range, including the DateTime.

Expected Behavior

The other operand should be typed as the range's inner type. type/2 around the literal is the workaround.

[matt-beanland]

I'm not sure if this really classifies as a defect, happy for it to be closed. The known workaround is to use type/2 to provide a type hint. Happy for it to be closed or to work on a fix/improvement as directed.

[zachdaniel]

I think this would be an issue on ash_postgres right?

[matt-beanland]

I was thinking a behaviour allowing any function (custom or otherwise) to provide its return type based on the types of its arguments might be the way forward? This came up with recent work on range, where the RangeLower, RangeUpper return type should be the inner type, but is just any.

[zachdaniel]

That should be doable in the current structure no? We have the :same type for that. i.e type: [[:any, :same]], returns: [:same] stuff like that.

[matt-beanland]

No I don't think it works here as both operands are range, and the return type is the inner type (assuming/checking both ranges have the same inner type). I was trying to avoid [:range, X] and have something generic that works with custom function. But maybe I need something like type: [[:any, :same]], returns: [:custom], then it delegates?

[zachdaniel]

ah, 🤔 yeah interesting. So you can include constraints in the the types, maybe we need to support some kind of nested any, like [{:range, left: :any, right: :same}], returns: [:same] or something. I think we have solved similar problems in other types but my recollection is failing me and I don't have time to check at this moment 😢

[matt-beanland]

Yes at the moment Ash.Type.Range has only baked inner types, but really a range could apply to any type that has certain properties (total ordering, and ideally canonical representation and sub-type ordering). In Postgres would be backed by a custom INTERVAL. It would be nice to sort this out but not a blocker.

[zachdaniel]

We can theoretically enumerate them I think, but it's not ideal and likely a hole in the way we declare function types. Probably a very complex implementation though TBH.

[matt-beanland]

Thanks I think we'll need to introspect them - a behaviour on Function.

[zachdaniel]

Function is already a behavior.

[matt-beanland]

Yes sorry i meant some more callbacks on existing Function behaviour, providing introspection. I'll have a play and report back.

[zachdaniel]

Sounds good, just be ready for me to potentially shoot the implementation down TBH 😓. The type resolution logic is quite complex and I may have to dig in personally to make it rich enough to support what are essentially algebraic types.

[zachdaniel]

i.e first<T>(Range<T, _>): T