Pgsql Doctrine Round Function Laravel Package

Technical Evaluation

Architecture fit

• Unchanged. This is not a Laravel package in the Eloquent sense — it is a Doctrine ORM DQL custom function registering ROUND() for PostgreSQL. It fits only where Doctrine ORM is the persistence layer and PostgreSQL is the database, or where it lives in a shared library consumed by a non-Laravel Doctrine service.
• For a pure Eloquent application it still has no architectural role; DB::raw('ROUND(col, 2)'), selectRaw, or a cast/accessor already cover the need.
• Where Doctrine is present, the fit remains narrow but clean: one FunctionNode subclass against Doctrine's sanctioned extension point (addCustomNumericFunction).
• No service provider, config publish, or facade — correct for what it is, but registration stays manual and per-EntityManager.

Integration feasibility

• Trial effort is still low: register, run one DQL query, inspect generated SQL and hydrated types.
• The 1.3 release changes the version-compatibility picture in one specific way: a new release means the constraint set has been refreshed, so it may now permit newer doctrine/orm and PHP versions than the 2019 build did. That is a hypothesis to verify from composer.json, not an assumption to act on. The release note carries no dependency information.
• The "First stable & working" wording is itself a compatibility signal — and a caution. If the author considers 1.3 the first stable release, then 1.0–1.2 were, by the author's own account, neither stable nor reliably working. Any prior evaluation, spike branch, or pinned ^1.0 constraint is now suspect.
• No Laravel-side artifacts were added, so registration is still manual and repeated per EntityManager/connection.

Technical risk

• Abandonment risk is materially reduced but not resolved. The dominant risk in the prior assessment — a package untouched since September 2019 — no longer holds literally. However, a single release after roughly six years of silence, with no dependents, no issue history, and no stated maintenance commitment, is a weak liveness signal rather than a durable one. Treat it as "resurrected," not "maintained."
• Version semantics are unclear. Jumping to 1.3 with "first stable" language implies either (a) breaking changes between 1.2 and 1.3, or (b) that 1.0–1.2 were effectively non-functional. Both readings mean the changelog/diff must be read before any version constraint is set. A caret constraint spanning the pre-1.3 releases is not safe.
• Zero adoption still means zero battle-testing. The release note is one line and discloses nothing about edge cases: null propagation, negative scale (ROUND(x, -1)), the round(numeric, int) vs round(double precision) distinction, or declared DQL return type. None of the prior open questions are answered by this release.
• Correctness risk stays modest but real, concentrated in DQL parsing, return-type declaration, and argument handling rather than the arithmetic.
• Supply-chain risk remains low in absolute terms (one small MIT class), but the package is still in the lockfile and in CVE scan scope.
• Opportunity cost is still near zero: roughly 40–80 lines to own outright, and now demonstrably prone to multi-year gaps between fixes.

Key questions

1. What actually changed in 1.3 — diff, changelog, or tag comparison? Is it a dependency bump, a bug fix, a rewrite, or a metadata-only release?
2. Which doctrine/orm and PHP versions do the new constraints permit, and does it install cleanly on the target stack without --ignore-platform-reqs?
3. Does 1.3 require Doctrine ORM 3.x, or does it still target 2.x only? This single answer moves the assessment more than anything else in the release.
4. Does it now implement both arities (ROUND(x) and ROUND(x, n)), and how is return type declared for numeric vs double precision?
5. Is there a test suite now, and does it exercise a real PostgreSQL instance rather than a mocked walker?
6. Is this a one-off revival commit or the start of maintained releases? Check commit cadence and whether tags are signed/annotated.
7. Does the organization's policy on unmaintained dependencies treat "one release after six years" as sufficient evidence of maintenance? Default answer should be no.

Integration Approach

Stack fit

• Unchanged. Adopt only where Doctrine ORM is the persistence layer and PostgreSQL is the database. Do not introduce Doctrine into an Eloquent app for this.
• Register per connection in Doctrine config (or the laravel-doctrine config), gated so it applies only to pgsql connections.
• Gate by driver if multiple connections exist; the function emits PostgreSQL-flavored SQL and must not leak onto MySQL/SQLite entity managers.

Migration path

• Preferred, and now more strongly preferred: fork or vendor the class into application namespace (App\Doctrine\DQL\RoundFunction) and register it locally. The 1.3 release is a useful source of any fixes to copy from, but adopting it as a standing dependency re-acquires the abandonment risk you would otherwise eliminate.
• Acceptable short-term: require ^1.3 specifically — never a range that can resolve to a pre-1.3 tag — for a spike, with an explicit ticket to vendor before the next Doctrine major upgrade.
• Not recommended: adopting as a long-lived dependency without a named internal owner, or pinning to ^1.0.

Compatibility

• Validate against the PostgreSQL version actually in production, not "PostgreSQL." numeric rounding is stable; implicit casts and double precision behavior depend on how the query is written.
• Do not rely on a SQLite-backed suite for validation. Tests must run against real PostgreSQL (CI service container or Testcontainers).
• Check result-set mapping and second-level cache interaction: a wrong declared return type surfaces as hydration type errors, which are harder to diagnose than SQL errors.
• If the team still runs Doctrine 2.x and 1.3 targets 3.x (or vice versa), the release is unusable this cycle regardless of its quality — confirm before sequencing work.

Sequencing

1. Diff 1.2 → 1.3 (or the 1.0/1.1 → 1.3 diff). Record breaking changes and dependency constraint changes. This is now step one and gates everything else.
2. Confirm Doctrine ORM presence, version, and the specific EntityManager(s) talking to PostgreSQL.
3. Spike in a branch: install at ^1.3, register, run one representative DQL query, inspect generated SQL and hydrated types.
4. Decide adopt-vs-vendor based on the diff and compatibility result; default remains vendoring, using 1.3 as the reference implementation.
5. Add an integration test against real PostgreSQL covering both arities and null input — this is the acceptance gate, not optional.
6. Register behind a driver check; document the function in the team's Doctrine conventions note.
7. If vendored, annotate with upstream repo, license, and the 1.3 tag as provenance.

Operational Impact

Maintenance

• Still treat as fully owned from day one. The 1.3 release does not establish a maintenance cadence; it establishes that the author was reachable once.
• Carrying cost is small — one class — but it belongs in the Doctrine-upgrade checklist. Every Doctrine major bump requires re-verifying the FunctionNode/SqlWalker surface.
• Vendoring reduces maintenance to "review when Doctrine changes," a scheduled task rather than a reactive one, and removes the question of whether upstream will publish a compatible version in time.

Support

• No meaningful community, issue history, or downstream users. Internal documentation and a named internal owner remain the entire support model.
• The release note is one line of prose with no upgrade guidance; it cannot serve as documentation. Write the internal note regardless of adopt-or-vendor.
• Expect new engineers to be unaware the function exists; without documentation they will reach for raw SQL, producing two conventions for the same problem.

Scaling

• Runtime overhead remains effectively nil: the function affects DQL-to-SQL translation at parse time only, and Doctrine's DQL query cache amortizes that cost.
• The real scaling concern is query shape, unchanged. ROUND(amount, 2) in a WHERE or JOIN predicate is non-sargable and bypasses plain B-tree indexes on amount. Plan expression indexes (CREATE INDEX ... ON t (ROUND(amount, 2))) or precomputed columns if the pattern spreads.

Failure modes

• Pre-1.3 behavior was, by the author's own framing, not stable or working. Any code or test written against 1.0–1.2 may be validating wrong behavior. Re-baseline rather than trust prior spikes.
• Hard failure at bootstrap/parse time: an incompatible class on a mismatched Doctrine version throws during query parsing, not container build — surfacing in production on the first query that uses ROUND.
• Silent semantic drift between versions: without a changelog, a patch-level movement inside ^1.0 could change rounding or argument handling with no review signal. Pin exactly if not vendoring.
• Silent semantic drift in PostgreSQL: ROUND(double precision) rounds differently from ROUND(numeric); a query passing in test can round differently in production if column types differ.
• Type hydration mismatch: an incorrect declared return type yields mapping/hydration errors or truncated values instead of a clear SQL error.
• Null handling: nulls should propagate; any deviation corrupts downstream aggregates.
• Convention fragmentation: half the codebase on the DQL function, half on raw SQL, making auditing and portability inconsistent.
• Driver leakage: registration on a non-PostgreSQL connection yields errors only when that path is exercised.

Ramp-up

• For an engineer comfortable with Doctrine internals (FunctionNode, SqlWalker, DQL parsing), ramp-up is under an hour. For an Eloquent-only engineer this is a new mental model and should not be their first Doctrine task.
• Cost is dominated by environment setup — a PostgreSQL-backed integration test harness — not by understanding the package.
• Net recommendation is unchanged in direction but firmer in reasoning: write it in-house or vendor 1.3 as a reference, and avoid a standing dependency on a package whose only evidence of life in six years is a single one-line release.