DBD::PgSQL: More Queestions

From: David Wheeler <david(at)wheeler(dot)net>
To: dbi-dev(at)perl(dot)org
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: DBD::PgSQL: More Queestions
Date: 2002-11-19 23:13:54
Message-ID: 927B7BCD-FC14-11D6-8737-0003931A964A@wheeler.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)wheeler(dot)net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message David Wheeler 2002-11-19 23:44:16 Re: DBD::PgSQL: More Queestions
Previous Message David Wheeler 2002-11-19 23:13:49 Re: DBD::PostgreSQL