DBD::PgSQL: More Queestions - Mailing list pgsql-interfaces
From | David Wheeler |
---|---|
Subject | DBD::PgSQL: More Queestions |
Date | |
Msg-id | 927B7BCD-FC14-11D6-8737-0003931A964A@wheeler.net Whole thread Raw |
Responses |
Re: DBD::PgSQL: More Queestions
Re: DBD::PgSQL: More Queestions |
List | pgsql-interfaces |
Greetings fellow DBI and PostgreSQL hackers. Yes, it's me the C and XS newbie who wants to write a new PostgreSQL DBI driver, back with more questions. Thanks for bearing with me. Status: I've just finished reading through DBD::Pg's dbd_preparse() and dbd_st_execute() functions, and they've left me with a *lot* of questions, which follow. Depending on the answers to these questions, I'll likely be deciding how to proceed with the development. This will naturally affect how long it will take to do the development (and I'm currently doing this in my [non-existent] spare time); I think it's going to take several months. Anyway, to the questions. First, a couple of general questions for the DBI folks: * What are the guidelines for handling trace? I note that DBD::Pg checks dbis->debug far more often than, say, DBD::mysql, and generally sets a lower threshold (1). What sorts of things should a driver be printing at what debug/trace levels? * In several of the functions, DBD::Pg starts with the statement "dTHR;". DBD::mysql, meanwhile, starts with this: #ifdef dTHR dTHR; #endif Which is correct, and what is this thing (variable) for? * In dbd_st_prepare(), is there a way to determine NUM_OF_FIELDS, NAME, etc. -- that is, before executing the statement? These next questions relate to the dbd_preparse() function in DBD::Pg. * DBD::Pg is doing a fair amount of work to work around SQL-style, C-style, and C++-style comments in SQL statements. Is this necessary? Are comments officially supported by the DBI spec? I notice that DBD::ODBC, for example, doesn't appear to do anything special with regard to comments. And if comments *are* supported by DBI, and DBD::Pg is doing the right thing by watching out for them, wouldn't it be smarter for DBD::Pg to cut them *out* of its internal copy of the SQL statement so that dbd_st_execute() doesn't also have to deal with them? * Dumb question: Can someone explain to me what's happening with the literal stuff? What is the parse doing, exactly? I have a general idea, but some of it is a bit opaque to my Perl-trained brain. :-) These questions related to the dbd_st_execute() function in DBD::Pg. * If the answer to the last question is "no", then in dbd_st_execute(), where DBD::Pg sets the number of fields, (sh|c)ouldn't this be done only once per prepared statement? I mean, no matter how many times a prepared statement executes, its number of fields won't change, will it? * With regard to the svp and phs variables, which get their values like this: svp = hv_fetch(imp_sth->all_params_hv, namebuf, i, 0); phs = (phs_t*)(void*)SvPVX(*svp); What are these variables, and where do they come from? I realize I'm showing my ignorance of Perl internals here, but I'm also trying to understand whether these variables are retrieving metadata from the PostgreSQL server. I understand that phs->ftype is checked to see if the value needs to be quoted, but I'm not sure where phs->ftype comes from. -- David Wheeler AIM: dwTheory david@wheeler.net ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: Theory@jabber.org
pgsql-interfaces by date: