- How do I install belamov/postgres-range in a Laravel application?
- Install it with Composer using composer require belamov/postgres-range. The package ships a service provider that Laravel auto-discovery registers, so no manual provider entry is normally needed. After that, add the package's range cast to the Eloquent models that own PostgreSQL range columns and confirm your PHP and Laravel versions satisfy the Composer constraints in the package's composer.json.
- Which PostgreSQL range types does this package support?
- The package is built for the common PostgreSQL range types: int4range, numrange, tsrange, and daterange, exposed to Eloquent as range value objects. That covers integer intervals, numeric or price ranges, timestamp windows, and date periods. Behaviour for other range variants such as tstzrange should be verified against your installed version, since timezone-aware bounds need explicit testing.
- Does belamov/postgres-range support Laravel 13?
- Yes. Release 1.3.1 is a patch release that adds Laravel 13.x compatibility and refreshes the package's test and tooling dependencies. No new features, breaking changes, or deprecations are called out in that release. If you are still on an earlier Laravel version, confirm the package's Composer constraints still allow it before upgrading.
- How do I cast a PostgreSQL range column to a PHP object in Eloquent?
- Declare the package cast on the attribute in your model's casts array, and Eloquent will hydrate the database range value into a range object instead of a raw string. From there you can read the lower and upper bounds and test whether the range is empty or unbounded. The same cast handles writing a range object back to the database on save.
- Can I query range overlaps and containment without writing raw SQL?
- Yes. The package provides query helpers for range operations such as contains and overlaps, so you can build where clauses in Eloquent instead of dropping into DB::raw expressions. This keeps queries readable and composable with your existing scopes and relationships. Check the generated SQL and execution plan on large tables to make sure the helpers map to index-friendly operators.
- How are empty, unbounded, and infinite ranges represented?
- Range values are returned as typed range objects, so you can query their bounds and state rather than parsing strings. PostgreSQL range semantics are subtle: an empty range compares differently from one with null or infinite bounds, and inclusive versus exclusive bounds change containment results. Test these boundary cases explicitly in your own suite, especially for timestamp and date columns.
- Do I need special indexes or the btree_gist extension for range queries?
- For containment and overlap filters, a GiST index on the range column is the usual choice; a plain B-tree index will not serve those operators well. If you also want exclusion constraints that combine a range with a scalar column such as a room or resource id, you need the btree_gist extension so GiST can handle the equality part. Review migrations and index strategy alongside adopting the package, since casting support alone does not make queries fast.
- Can I use this package with MySQL or SQLite?
- No. This is a PostgreSQL-specific adapter that depends on native range types, so it will not work on MySQL or SQLite. It also is not a good fit for database-agnostic products where the persistence layer must stay portable. Adopt it only in Laravel services that are already committed to PostgreSQL.
- Is it safe to upgrade to version 1.3.1 in production?
- Release 1.3.1 is a patch-level update focused on Laravel 13 support and dependency refreshes, so the functional risk is low. Still upgrade on a branch, review the lockfile diff for transitive constraint changes, and run your suite against a real PostgreSQL instance matching production's major version. Confirm the application's current Laravel and PHP versions are still supported before merging.
- Is belamov/postgres-range actively maintained and what are the risks of depending on it?
- It is a focused, single-purpose persistence utility with a small surface area, which limits functional risk. The main concerns are maintainer concentration and release cadence, so check the license, recent commit history, and issue responsiveness before standardising on it. Pin it with a narrow constraint such as ^1.3.1 and treat it as a persistence-layer helper rather than a platform dependency.