-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
> Ug. I`ve just looked at the code for _prepare and it does look inefficient.
> Multiple scans of the string and multiple memory allocations.
> Certainly some room for improvement there.
 
That whole section has been ripped out and rewritten - the upcoming version
(1.40) will be completely different from the exisitng version (1.33). I am
pretty sure that problem has been resolved along the way.
 
> There`s no need for the fetch code if it`s about the same as Pg.
> But I suggest making the NULL change and the utf8 changes I mentioned.
 
I made the null change - it seemed logical to me. I also factored out the
column type checking: it stores the column types at the imp_sth level and
only makes those calls the first time through. Not sure about the utf_8 stuff:
as Rudy mentioned, the default is still "off".
 
I doubt there is much of a speed difference at any rate between DBD::Pg
and pgperl (calling it Pg.pm is just downright confusing, as that's the
main Perl file used by both projects). It's not likely that the new placeholder
parsing slows it down by anything noticeable, and it should be more than
outweighed by the fact that DBD::Pg uses (or will in a couple weeks)
server-side prepares.
 
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200412181142
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
 
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFBxQe9vJuQZxSWSsgRAkKvAKC4IIvPxXdYjAeSlPoAFAvhI/xWtQCeIdO+
16j56HUHWLJQ8ODzI80omeA=
=KN0B
-----END PGP SIGNATURE-----


Reply via email to