Hi; I have released the cpan modules which handle serialization and deserialization. The logic is currently spread between three modules. I would be happy to try to help refactor some of the logic into DBD::Pg if it belongs there (specific proposals below). And while the code is not really where I want it, it currently works. In coming weeks you can expect refactoring and an improved API between the components.
The logic is currently spread between four modules: 1. PGObject::Type::Composite has a basic API for learning db structure associated on a db level, serializing and deserializing. 2. PGObject::Util::PseudoCSV parses the tuple and array formats. This necessarily duplicates some functionality in DBD::Pg, so wondering about making the array parsing code there more general and a public API (something like $dbh->parse_literal($string)) and getting rid of this module entirely. 3. PGObject::Util::Catalog::Types provides a functional interface to the type catalogs. Currently this is limited to type lookups but there are plans to add ddl facilities as well. 4. PGObject has a registry system which allows detection of auto-serializable data types to the db (if it has a to_db() method, we call it). It also allows for custom types to be registered for handling data retrieved from the db. So for example numeric can be mapped to a subclass of Math::BigFloat providing the necessary interfaces and conversion will happen on retrieval. I don't know if this would be worth adding to DBD::Pg but if there is interest I could do that. Having the type registry at a lower level would make things more consistent since one could register a type and have it handled regardless of whether the query is a stored proc called from PGObject or otherwise. -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
