Dan Sugalski wrote:
Dunno if I replied, but... Next step is a higher level wrapper, if
you're up for fiddling with Postgres itself. Stuff like a single call > to connect (right now you have to make the connect call and poll over
and over again),
I did some benchmarks using your original library a few weeks ago and I did find the polling business a bit odd.
I replied a while back asking asking if anyone had any pointers or examples on where to start this no matter how simple but I think "Warnock's Dilema #2" may have kicked in.
D'oh! I thought I'd replied, but I guess not.
Being fairly new to parrot and probably naive I can see a few different ways of doing this.
A C wrapper ie: parrot/classes/parrotdbi.pmc etc A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc A loadable pasm function library that uses the current libpq/(other libs) and available available ops.
I'd go with option 3, the loadable pasm library that uses the current libpq. I think that, right now, there's no need for anything else. That may turn out to be incorrect, but if so we can try Plan B. (Which involves either extending Parrot or getting the C extension stuff working)
Tim's right -- dodge the DBD/DBI names for right now. We're going to have enough of a headache with those later, what with there being both Ruby and Perl versions that use it. (Possibly Python too, I'm not sure)
> getting back a full row as an array, getting back a fullrow as a hash, and stuff like that. Nothing fancy, and nothing that high-level, but enough to work the basics without quite as manual work as the current libpg requires.
This'll probably be the basis for the DB driver interface for Parrot's DBI library, so this is your chance to make a mark. :)
Cheers for the opportunity.
Always happy to pass on work to other people. :) -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
