Re: DBD::PgSQL: More Queestions - Mailing list pgsql-interfaces
From | David Wheeler |
---|---|
Subject | Re: DBD::PgSQL: More Queestions |
Date | |
Msg-id | 5C9E6A6E-FCF5-11D6-8943-0003931A964A@wheeler.net Whole thread Raw |
In response to | DBD::PgSQL: More Queestions (David Wheeler <david@wheeler.net>) |
Responses |
Re: DBD::PgSQL: More Queestions
(Tim Bunce <Tim.Bunce@pobox.com>)
|
List | pgsql-interfaces |
First, I want to thank everyone who has responded to my posts. I know that they're chock full 'o newbie questions, and I *really* appreciate the patient explanations that all you folks are taking the time to send to me. I *really* appreciate it. The only side affects are that I now have to spend much more time writing and responding to emails, and that I'm much more motivated to spend the time getting to know the code so that I have the knowledge to create an effective update. I couldn't have done it without you all. Thanks! On Wednesday, November 20, 2002, at 02:49 AM, Tim Bunce wrote: > Drivers should rarely if ever print anything below trace level 3. > Quite a few drivers get this wrong and it can be quite annoying to > the users to have to wade through lots of driver output when all > they want is the basic DBI level 1 or 2 trace. Use levels around > 4 through 7 to add more (obscure) detail. So, 4 for more informative stuff, and down through 7 to report, say, every function executed? > I believe dTHR is only needed for the old "5.005 threads", not the > new iThreads, and the DBI will no longer support the old 5.005 threads > so you can delete them all for your new driver. Okay. Thanks for the tip. > Some databases, like Oracle, have what you could call a "server-side > prepare" so DBD::Oracle's prepare() method sends the statement to > the server and then asks the server to 'describe' it. PostgreSQL 7.3 has a "server-side prepare" that I'd like to take advantage of, but I don't think it offers any way to then "describe" the prepared statement. > (Without that you'd need a full sql parser available on the client > side. Even then you wouldn't know the TYPE of the database fields > without much more work.) Yep, I'll steer *far* clear of that! :-) > That's the wrong question. The DBI spec actually makes no assumptions > about the syntax of the statements. But it does say that question marks > should be used for placeholders. > > Thing is, users tend to get upset (quite reasonably) when a driver > interprets question marks that are inside comments as real > placeholders. I guess I've never seen users use comments in SQL they're passing to the DBI. I personally tend to use Perl comments. > Personally I'd agree with them that it's a driver, er, limitation > (so I'm not over-happy with DBD::ODBC ducking the issue, but I > understand that DBD::ODBC faces a much tougher issue here than most > drivers). Okay. Perhaps I'll leave it in, then. But if I decide not to use PostgreSQL 7.3's server-side prepare functionality, and I still need to parse statements for every execute, I think that I might then eliminate them from the query in dbd_preparse() so that dbd_st_execute() doesn't have to worry about them. > Why should dbd_st_execute have to "deal" with them? The whole string > should just be sent off to the server. I believe that others have answered better than I. The short answer: no support for sever-side prepare up to now, so dbd_st_execute has to parse the statement again every time. > If it's possible for you to _realiably_ determine the number of > field at prepare() time, then you should do it. If not, then do it > on just the *first* execute(). Yeah, I'm not sure that I want to do that kind of parsing in dbd_preparse. > phs stands for placeholder structure. The structure (typedef) is > declared > in one of the driver *.h files. There's one per placeholder and they're > store in the hash pointed to by imp_sth->all_params_hv. All that's done > by dbd_preparse() as it scans the statement string. Thanks. With the help of some of the other replies (notably Jeff's), and careful examination of DBD::Pg's and DBD::ODBC's code, I think I'm starting to follow what's happening there. Thanks again for the help, Tim! Regards, David -- David Wheeler AIM: dwTheory david@wheeler.net ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: Theory@jabber.org
pgsql-interfaces by date: