On Wednesday, November 20, 2002, at 11:53 PM, H.Merijn Brand wrote:
#ifdef's tend to get stuck on `true' :)
True. Um, I mean, *correct*.
Once you start, you will see that the driver will never be /finished/. EitherAll true. I'd like to get it to a place that makes maintenance easier than it currently is with DBD::Pg. I'm a *big* fan of comments, for example.
you have to add features, after yet another DBI enhancement, or you have to
change the interface calls because the binding libraries change, or some end
user has found a way to crash your driver using some weird undocumented
feature or ...
End of the line is that external controlable debug behaviour turns out to beI think I might lean toward just using DBI's trace functionality, and then dealing with the verbosity when it's set high. But that's just me.
much more useful than ifdef's. And you can than always ask some end user on
weird system AxyDfs-3.45a to run the same code with $dbh->{DBDverbose} or
$sth->{pg_sth_debug} to some useful value.
HLI High Language Interface. Usually a set of functions grouped in a set ofAh, yes. PostgreSQL only offers an E/SQL solution on the client side (they have "SPI" for server-side). So everything will be executed as an SQL query.
libraries that enables you to write your own C/Pascal/Fortran/... code
to use the database
E/SQL Embedded SQL. The .xs does not have direct calls to the HLI, but needs
a preprocessor specific to the target database to translate the SQL
statements to HLI before the real C compiler can deal with it.
Since E/SQL is translated to HLI by a preprocessor, it will close to never be
as efficient as when you'd written the HLI yourself, but it is much more
readable, and for sure a lot more portable.
Oh man, I've been there for a *while*! I'm just foolish enough to *continue* to put more on my plate. Ah, well!Welcome to this neverending world of tuit shortage :/
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
