On 15 Nov 2001, Jason E. Stewart wrote: > > None of other postgresql interfaces (JDBC, libpq) provide any kind > > of support dealing with arrays, and I think it probably will be > > misplaced to do it in DBD::Pg. > > They presumably support exactly what Perl currently does: arrays look > like strings. Or do they not support that at all? Yes, they support exactly that.
> > To work around it, its fairly easy. Make a function to > > serialize/deserialize array ref, and call it at appropriate moment. > > True. I just wanted to have a way to do it in C so that it would be > fast. I want to access arrays of 6 floats in tables with a million > rows, doing that using perl's split() and join() is going to be slow. Well, split/join _are_ written in C ;) > > If you really want to get it in DBD::Pg, write a patch :) > > That's what I'm offering ;-) > > I was just hoping that someone could tell me if there is some > fundamental obstruction in the DBI C API that prohibits using RV's. In > Pg's dbbimp.c it wants to convert all the bind variables into > char*'s. I don't think there's a problem. > I'm hoping that this is because that's what Pg wants and not what DBI > forces you to do. > > > Oh, and you might want to consider DBD::PgSPI and plperlu on server end, > > this way you can serialize complex structures and pass them to a > > server-side perl program :) > > Thanks for pointing that out. I was disappointed that PL/Perl didn't > allow access to the DB, so I never used it. I grabbed your module and > the latest beta and dug around in the code. But I couldn't figure some > stuff out. > > Am I forced to serialize them into strings? Or can I return arbitrary > SV's from the functions? Yes, you must serialize. The idea is that you use FreezeThaw or Storable method to serialize your incoming data before passing it along to database. Your data can be as complicated as you want (hashes of arrays of hashes, etc). On database side, you deserialize them and process. Then again, you serialize the return value[s] and decode them on client side. > in plperl.c, plperl_func_handler() does: > > retval = FunctionCall3(&prodesc->result_in_func, > PointerGetDatum(SvPV(perlret, PL_na)), > ObjectIdGetDatum(prodesc->result_in_elem), > Int32GetDatum(-1)); > > which rips a string out of the perlret SV. So my guess is you have to > return a string from your function. What about using > bind_param_inout()? The DBD::Pg man page says this isn't supported, > but would implementing this enable me to pass back RV's? PostgreSQL doesn't support out/inout parameters... -alex
