DBD::PgSQL: More Queestions

Поиск
Список
Период
Сортировка
От David Wheeler
Тема DBD::PgSQL: More Queestions
Дата
Msg-id 927B7BCD-FC14-11D6-8737-0003931A964A@wheeler.net
обсуждение исходный текст
Ответы Re: DBD::PgSQL: More Queestions  (David Wheeler <david@wheeler.net>)
Re: DBD::PgSQL: More Queestions  (Tim Bunce <Tim.Bunce@pobox.com>)
Список 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 по дате отправления:

Предыдущее
От: David Wheeler
Дата:
Сообщение: Re: DBD::PostgreSQL
Следующее
От: David Wheeler
Дата:
Сообщение: Re: DBD::PgSQL: More Queestions