- Can I install fle/postgresql-type-bundle in a Laravel application?
- Not as a drop-in dependency. It is a Symfony bundle that relies on kernel bundle registration, a DI extension and config.yml service wiring, none of which Laravel provides. The only reusable part is the underlying set of Doctrine DBAL type classes, and those target DBAL 2 and would need porting before use in a modern Laravel app.
- What PostgreSQL types does this bundle actually add to Doctrine?
- It provides Doctrine DBAL Type subclasses that teach Doctrine how to map PostgreSQL-native columns such as hstore, array, json and inet/cidr to PHP values, plus the Symfony bundle class and DI extension that register them. Check the source for the exact list, since the bundle is archived and documented only by its README.
- Does this bundle work with Doctrine DBAL 3 or 4 and PHP 8.2+?
- Almost certainly not without modification. The code dates from the Doctrine DBAL 2 and Symfony 2 era; DBAL 3 changed Type method signatures and deprecated getName(), and DBAL 4 removed getName() entirely and requires typed AbstractPlatform parameters. On PHP 8.2 or newer with a current DBAL you should expect fatal errors or silent mis-mapping until the classes are re-typed.
- Do I need this bundle if I only use Eloquent and Laravel migrations for hstore or inet columns?
- No. Eloquent does not consume Doctrine DBAL type mappings at all; it uses PDO, and PDO already returns most exotic PostgreSQL values as strings, which you can shape with $casts. If you only need hstore or inet columns declared in migrations, a raw DB::statement or a schema macro is cheaper and safer than adding a dependency.
- How do I map PostgreSQL hstore or array columns to PHP values in Laravel?
- On the Eloquent side, store the value as text or jsonb and cast it in the model. If you genuinely need DBAL-level mapping, for example inside a Doctrine-backed bounded context, you would register a Type implementation via Type::addType() in a service provider, but you should write or vendor that class against your pinned DBAL version rather than installing this bundle.
- Is there a maintained alternative to fle/postgresql-type-bundle?
- Yes, martin-georgiev/postgresql-for-doctrine is actively maintained and covers considerably more PostgreSQL types. For most teams it is the correct answer. Compare its supported DBAL versions against your pin before committing.
- How would I vendor only the PostgreSQL type classes into my own app?
- Copy only the one to three type classes matching columns you have verified in your schema, not the bundle, the DI extension or the unused types. Re-type the method signatures against your pinned DBAL version, add declare(strict_types=1), place them under a distinct namespace such as App\Doctrine\Types, and register them with Type::addType() in a service provider so a future swap is a search-and-replace.
- The package is archived with zero dependents — is it safe for production?
- Treat it as high risk. The repository is archived, has a handful of stars and zero dependents, and targets a DBAL generation that no longer exists on current stacks, so nobody is exercising it against modern dependencies. The dangerous failure mode is silent: a wrong getSQLDeclaration or convertToPHPValue can emit the wrong column type or corrupt data rather than throwing.
- How do I register a custom Doctrine type in a Laravel service provider?
- In a service provider's boot method, call Type::addType('hstore', HstoreType::class) once the DBAL Type registry is available, and guard it so it only runs once. Doctrine consults these mappings through DBAL only, so this has no effect on Eloquent queries; it matters for schema generation and any Doctrine-managed connection. Test the registration against your pinned DBAL major version.
- What are the failure modes if I use these types on a newer DBAL version?
- Beyond hard errors from changed method signatures, the realistic risks are incorrect DDL from getSQLDeclaration and convertToPHPValue returning null or a string where an object is expected. Because these surface at query or migration time rather than at boot, they tend to reach production. Keep an owned test suite over each vendored type if you go that route.