Composite type serialization update

[Chris Travers]

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