On Mon, Aug 25, 2014 at 10:52 AM, Greg Sabino Mullane <[email protected]> wrote:
> On Sun, Aug 24, 2014 at 05:33:04PM -0700, Chris Travers wrote: > > I would love to see this in DBD::Pg. However there are some complexities > > here not present in arrays. Arrays are at least in theory > self-contained. > > We don't have to ask the db how to parse them. Tuples are not (we need > to > > do a catalog lookup to find the order of elements). > > The biggest problem is that any composite types are going to be > user-defined > types, and thus DBD::Pg cannot know about them in advance (as it does for > arrays). This problem has reared its head already. We can query the system > catalogs to gather information about data types, but the key point is when? > On connection? When we encounter an unknown type? (tricky, as we are > already > inside of an active transaction). Perhaps allow the user to call some > method > that tells us to grab the information? I'm thinking some combination of > the former and latter will work: allows a connection attribute that says > "grab information about all user types right after you connect" as well as > a > method that does the same thing (or allows some wildcards, etc.). Once that > is in place, it should be relatively easy to roll multiple columns into a > hashref .. I think. Haven't actually dug into that part of the code yet :) > I think for memory reasons, having a special call would be the way to go. It may be helpful later to provide to make that call when a bind_param() is called with a user defined type, or when a tuple is encountered. But I guess this leads to a long-range question: do we want to be making all kinds of decisions regarding serialization and deserialization in DBD::Pg. If not, do we want to have standard interfaces to allow folks to specify their own serialization and deserialization (perhaps with some utilities for accessing common catalog information)? I guess what I am wondering is how far we should scope this in DBD::Pg and how much we should try to hand off responsibility elsewhere. Best Wishes, Chris Travers > > -- > Greg Sabino Mullane [email protected] > End Point Corporation > PGP Key: 0x14964AC8 > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
