Sorry, I must have misread an old post about this. If folks are interested in the work I am doing here, what I am looking at right now is a combination of a function called stringify and I could eventually write a unstringify function. If it is helpful, and folks want it, I have no problem contributing the functions to DBD::Pg as they mature.
The function requires at least two arguments. The first is a string that specifies the name of the complex type. Subsequent arguments are hashrefs matching that type. I first check to see if the type is cached, and if not, look up the attribute names via pg_attribute and pg_class. The attribute list is then cached, so the next time the type is called, we know what the attributes are. This prevents a great deal of overhead from repeat calls and assumes that in most scripts you see a large number of calls for a small number of types, rather than a small number for each of a large number of types (which might justify building the cache at connect time). Currently this cache is global to my module but if I were to at some point merge it into DBD::Pg, I suppose I'd want to tie the cache to the db handle. Right now, it's pretty basic. Long-run it would be nice to add support for nested types, esp. where arrays of complex types may be elements in the tuple, but for now, that's not as necessary in my use case because I don't have any that are more than one deep and select * from.... corrects that without adding array parsing.... Best Wishes, Chris Travers
