Re: DBD::PgSQL: More Queestions

[David Wheeler]

On Wednesday, November 20, 2002, at 04:51  AM, H.Merijn Brand wrote:

I've added a driver specific verbose setting to be able to see driver specific
debugging. IIRC, Tim didn't agree with the name, so I have to change it
sometime, but - certainly in the development phase - it might be very handy to
skip the DBI debug, and only see the driver specific dubugging

my $dbh = DBI->connect (....);
$dbh->{DBDverbose} = 9;

is what I have currently implemented in DBD::Unify
where the highest of this internal verbosity level or DBI's trace level is
used for reporting. Again, this internal level is probably only usefule for
people that are conbcerned with the specific DBD implementation (like you are),
and not the end user.

Right. I think I'd be more likely to add use ifdefs or a macro or something during development...

So if you are going to support this driver from 5.6.1 and up with no need to
go back, just leave these out.

FWIW 5.8.0 could still be build with 5005 threads, though it was marked
depricated and unsupported. In 5.9.0 (the development track), *all* 5005
thread support has been removed.

If I leave it out, will *un*threaded perls prior to 5.6.1 work without dTHR? If so, then I just might leave it out, since no one in her right mind uses threads before 5.8.0 for production code. Probably not even 5.8.0, come to think of it.

I don't know if you are writing the XS in HLI or in E/SQL, but most HLI or
E/SQL have describe functions. My DBD::Unify is completely written in E/SQL,
so take a peek in there to see how describe works. E/SQL is most often slower
than HLI, but much more portable. DBD::Unify is not to be taken as an example
driver, because it (still) lacks a lot of funtionality. If you want to `steal'
code, use DBD::Oracle and DBD::ODBC, that's how I started DBD::Unify :)
[ Thanks Tim, Jeff, and other authors ]. Good aditional `example' drivers to
steal from are also FreeTDS and Ingres.

Um, "E/SQL" and "HLI"? I'll have to Google for those when I'm off this plane, had a good night's sleep, and back online. I'll definitely check out DBD::Unify, though; thanks!

Because some database interfaces need to pass storage space along with the
retreival statement, so you need to know how many input and output variables
are expected before you pass it.

Well, for PostgreSQL, it's because DBD::Pg has been doing the parsing for placeholders and replacing them with the proper values.

Same issue as comments. Consider this statement:

    SELECT * FROM table WHERE a = ? AND b = '?' /* is this right? */

An unquoted question mark is a placeholder. The driver should take care of the
neccasary conversions. So if a is a numeric, the driver should take care that
"1" is correctly converted to the required format.

DBD::Pg can only do this if bind_param() passes in the proper data type constants.

Thanks for your comments!

Regards,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]