Pgsql Doctrine Round Function Laravel Package

Product Decisions This Supports

• Build vs. buy on a single SQL function: This package still answers one narrow question — "how do we get ROUND() into Doctrine DQL against PostgreSQL?" — and the answer remains "register a custom DQL function." Release 1.3 ("First stable & working") does not change the shape or size of that work; it confirms the code is now functional rather than introducing new capability. Treat it as a reference implementation (~30–60 lines of FunctionNode plus a Doctrine\ORM\Configuration registration), not a platform dependency.
• Feature scoping for a reporting/analytics surface: Any roadmap item involving currency rounding, score aggregation, KPI rollups, or "round to N decimals in the query layer" will hit this exact gap. The estimation is unchanged: one FunctionNode subclass plus a registration call, now with a known-good upstream example to crib from.
• ORM boundary decisions: The package remains a prompt to decide where rounding happens — in SQL (consistent across all consumers, index-friendly, but DB-dialect-specific) versus in PHP (portable, testable, but pulls more rows). This architecture call still precedes any package choice and still deserves a one-page decision record.
• Portability / vendor-lock-in roadmap: Still Postgres-only. A second database (MySQL, SQLite for test suites) means a migration tax, which argues for application-layer rounding unless there is a measured performance reason otherwise.
• Dependency policy calibration: The 1.3 release is a meaningful but limited signal — it shows a maintainer is intermittently active, which softens the "abandoned since 2019" read but does not establish a support cadence, a changelog, or a compatibility policy. A one-line release note reading "First stable & working" also implies prior versions were not reliably usable, which is a caution flag for API stability, not a reassurance. The standing rule still holds: for sub-100-line functionality with no meaningful user base, vendoring with attribution and tests beats a Composer requirement.
• Not a build-vs-buy candidate for anything strategic: No vendor, no support tier, no licence exposure (MIT), no ecosystem. It cannot inform pricing, packaging, or partnership decisions. Its product value remains that of a reference implementation.

When to Consider This Package

Adoption criteria — all of these should hold before adding the dependency:

• You are on Doctrine ORM (not Eloquent), with PostgreSQL as the only production database, and you genuinely need ROUND() inside DQL — i.e. in WHERE, ORDER BY, or SELECT expressions that must execute in the database rather than after hydration.
• You have confirmed the DQL parser extension is compatible with your current Doctrine ORM major version. The release history is thin and predates the ORM 3.x era, so verify FunctionNode API compatibility explicitly rather than assuming 1.3 addresses it — the release note claims stability, not currency.
• You have read the full source and are comfortable owning it, because you will be the maintainer in practice. Intermittent releases are not support.
• The cost of writing it yourself is genuinely higher than the cost of vetting and vendoring it — which, for a rounding function, is almost never true.

Look elsewhere (or build in-house) when:

• You are on Laravel Eloquent. Doctrine-specific and does not apply. Eloquent users get rounding from DB::raw('ROUND(...)') or a select expression; close the ticket.
• Your test suite runs on SQLite or you otherwise need dialect portability. Round in PHP instead.
• You need more than ROUND(). If you are accumulating custom DQL functions (date truncation, GREATEST, string aggregation, window functions), adopt a maintained, cohesive custom-function library rather than assembling one micro-package per function.
• Any security, compliance, or SLA context applies. A dependency with a single recent one-line release and no published maintenance policy is still a procurement and audit liability disproportionate to any benefit here.
• Recommended default: write the FunctionNode yourself (roughly 30–60 lines), cover it with an integration test against Postgres, and keep it in your own codebase. The MIT-licensed 1.3 source is a usable starting point if you want a reference.

How to Pitch It (Stakeholders)

For executives: We re-reviewed a small open-source component that adds a ROUND() database function for Postgres-backed Doctrine queries. It has just shipped its first stable release (1.3), which is a positive signal, but a single release with a one-line note — following a long gap and implying earlier versions did not work — is not evidence of sustained maintenance. Recommendation unchanged: do not adopt as a dependency. The capability is a few dozen lines we can own outright. Taking it on adds an unsupported external dependency and a Postgres-only coupling to our data layer in exchange for saving perhaps half a day. The strategic takeaway is that our dependency-vetting threshold is working: small gaps like this should be closed in-house, and a single "first stable" release is not by itself grounds for reclassification.

For engineering: This is a Doctrine DQL custom function registering ROUND() for PostgreSQL — a FunctionNode subclass plus a Configuration::addCustomNumericFunction call. Two constraints before anyone reaches for it: it is Doctrine ORM only (irrelevant to Eloquent), and its release history gives no evidence of Doctrine ORM 3.x compatibility, so verify before assuming. Version 1.3 is described only as "First stable & working," with no changelog, so treat that as a functional baseline rather than a compatibility guarantee. The action item is a short spike: implement ROUND() as an internal FunctionNode with an integration test against Postgres, using 1.3 as a reference if useful. Decision to record: whether numeric rounding belongs in SQL or in the application layer — SQL for aggregation-heavy reports and cross-consumer consistency, PHP for database portability and easier unit testing. Do not add the Composer dependency.