-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
No time to respond fully, but a few cents here and there, with some devil's advocate thrown in. Darren Duncan wrote: > All host parameters should be named (like ":foo") rather than > positional (like "?"), meeting with the SQL:2003 standard. The named > format is a lot easier to use and flexible. I don't know about easier. I like the question mark for quick little queries, and you can simply call execute with a single argument, for example. Can't get easier than that. :) I also would probably prefer the $1,$2,$3,..$N style over the :foo style myself. I can see room for all of them, but all of this is really a DBD, not a DBI, issue. The DBI module could certainly more strongly recommend one of the '?' alternatives. > and not some alternate or abbreviated version that either leaves > the 'DBD::' out or is spelled differently I mostly agree with this, but it's not as if every DBI release adds a whole bunch of new DBDs. I'd at least try and keep a common prefix. Sam Vilain wrote: > So, effectively the prepare can happen at any time, and it's up to the > DBD to decide whether to actually do anything with it immediately or not. > ie, on Pg the STHs would be built before the DB is connected, and on Oracle > they are built the first time they are used (and then cached). Actually, Pg uses server-side prepares whenever possible, so this would be of limited use to it as well. I know mysql is going that way as well, so I'm not sure how useful all of this will be. I also don't know if all these contortions will really save all that much: if performance is that much of an issue, you can certainly use mod_perl to prepare them once (with or without a database) in your BEGIN block, and execute thousands of times after that. Darren Duncan again: > Each DBI driver can worry less about that its input is correct and focus more > on its actual work. Can you expand on this a little? Not sure I understand: DBI already validates the number and type of the common methods. I *know* we aren't talking about a global SQL parser - that way lies madness. :) > A $sth should not contain any methods for fetching the result of > an executed statement; ... > my $rlh = $sth->execute(); > my $rowset = $rlh->fetchrow_arrayref(); > > This approach is a lot more flexible. This seems like an unnecessary step. Fetching data seems like a normal method for a statement handle. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200507072132 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 P.S. No reason to cc dbi-dev, everyone there should be on users, and no reason to cc Tim, he's on both. Doesn't seem particularly perl6 related now either... :) -----BEGIN PGP SIGNATURE----- iD8DBQFCzdgYvJuQZxSWSsgRAhWAAJ49XoMjTWhOQ7ddqKmjvthtqyakOACgk9kI IMIKahnbi+kyQCrxOUnSbr4= =3Zkw -----END PGP SIGNATURE-----
