-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
Andrew Dunstan wrote: > We really badly need to get better support into libpq for array and > composite types. > > I'm prepared to help if you want to go down that road. If by "go down that road" you mean use such a thing in DBD::Pg, I could get behind that. Mind you, it will be a long way away before we could use such a thing due to the libpq library problem, so it's most likely the libpq bits would merely become a future enhancement to code that is already inside of DBD::Pg. (thinks...) At which point, why bother, as it's one more piece of external code to worry about, and is unlikely to be as fast as doing it ourselves (or at least, no faster). Sorry to come nearly full circle there, but at this point, I can't see any libpq enhancements really making a difference in DBD::Pg development. The time lag and code forking would just not be worth it, if there is any way at all we can implement the thing ourself. The long-term goal is to move away from libpq entirely (not to say it hasn't been incredibly useful so far, of course). Chris Travers wrote: > I think that Greg is right that the overhead is too much for every > run, esp. when 99% of the apps out there won't need it but I still > would find this very useful. Well, to be contrary :), the overhead will be hardly anything if you haven't defined any custom types in your database. It's a single lookup across a few system tables, and if it returns no rows it should be minimal. > If there are other ways to help, I would be glad to do so. Help in developing the API would be the best thing for now[1]. Examples of real-life work that is using custom types right now would be helpful too. Once we have a semi-working API, you could make some tests. More tests are always good. :) [1] On quick thought, might be nice to map the type names as well for use in bind_param calls. > Anyway-- thoughts on this: Most apps should be able to get by > specifying what custom types they need to know. It is not clear from > Greg's email if this is the case, but it would seem to me that the > function to learn the types should be one which allows specifying > specific types, which could then be looked up in advance. I was envisioning just sucking them all in. It's highly unlikely that there would be enough in use to worry about time or memory considerations. Back to the API - how would you envision an app specifiying the custom types? > Also another option has occurred to me-- that it might be better just > to move this out of DBD::Pg and have another Perl library which allows > for this parsing. I'm not sure I see the advantage of that, nor is it clear what exactly would get moved out. Right now, these are the separate pieces that the patch will have: * New flags to control if we slurp or not. * New structures in dbdimp.h to hold custom type information * Routine to query the catalogs and transform to the structs. * Routine to transform the fetched data into Perl objects, using the struct information. * Routine to transform the Perl hashrefs in bind_param to a Postgres-friendly input string. The first three are done, the fourth is partly there, and the fifth has yet to be tackled. David E. Wheeler wrote: > Nice. Would this work for hstore types, then? Don't think so. (tests...) Nope. It doesn't create a composite type in the pg_class table, for one thing. I'll put looking into it on the todo though. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200806090003 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkhMrlkACgkQvJuQZxSWSsgRtgCgv2wFasI4W8C46GozG1IqhWCM 3zQAn1nhq8gTus3rAhPrUoVZOxK8R5NK =Wd7v -----END PGP SIGNATURE-----
