Getting Started

Treat 5.0.0 as a maintenance/compatibility baseline. First confirm the application and CI images meet PHP >= 7.2; this is the only explicitly breaking requirement in the release notes.
Read CHANGELOG.md first. This release adds a changelog file, so future upgrade decisions should reference it before reading commit history.
Install/upgrade with the normal Composer workflow, then run the application test suite against a PostgreSQL connection, not only SQLite/MySQL.
First use case: exercise the sanitization path that previously failed on PostgreSQL. Take representative input containing quotes, backslashes, Unicode, and SQL-sensitive characters, pass it through the package sanitizer, persist/query it through a pgsql connection, and assert the stored/returned value.

Implementation Patterns

Keep package usage behind a small application service, action, or form request rather than scattering sanitizer calls across controllers. This makes the PostgreSQL fix easy to verify and keeps future upgrades contained.
Sanitize at the boundary where data enters the application, then validate the sanitized result. Avoid sanitizing repeatedly in multiple layers unless the package explicitly documents idempotent behavior.
Add a dedicated PostgreSQL integration test for the sanitizer. Use Laravel’s pgsql connection, RefreshDatabase or transactions, and fixtures that cover the edge cases the release note calls out.
If the package exposes configuration, publish it and keep environment-specific values in config/ and .env; do not hard-code database connection assumptions.
For upgrade work, run composer update for this package only, then run the full test suite with PostgreSQL enabled. Compare sanitizer output before and after the upgrade for representative inputs.
If the package provides a facade or helper, prefer dependency injection or a thin wrapper in application code so tests can substitute or spy on the sanitizer when needed.

PHP 7.2 is now required. Check composer.json, Dockerfiles, CI matrices, and deployment images before upgrading; applications still on PHP 7.0/7.1 must either upgrade PHP or pin the previous package major.
The PostgreSQL sanitization fix may change output for edge-case input. Add regression tests for quotes, backslashes, null bytes, multibyte strings, and values used in where clauses or raw expressions.
Do not assume SQLite/MySQL test coverage validates this release. The meaningful change is PostgreSQL-specific, so keep at least one CI job running against PostgreSQL.
The new changelog is useful, but this release does not document API changes beyond the PHP requirement and PGSQL fix. Inspect the diff or release commit if you rely on sanitizer internals.
Use the package’s documented extension points—published config, custom bindings, or overridable sanitizer classes—rather than forking. If behavior differs between database drivers, isolate that in application code and document it.