Re: DBD::PgSQL: More Queestions

[David Wheeler]

First, I want to thank everyone who has responded to my posts. I know that they're chock full 'o newbie questions, and I *really* appreciate the patient explanations that all you folks are taking the time to send to me. I *really* appreciate it. The only side affects are that I now have to spend much more time writing and responding to emails, and that I'm much more motivated to spend the time getting to know the code so that I have the knowledge to create an effective update. I couldn't have done it without you all. Thanks!

On Wednesday, November 20, 2002, at 02:49 AM, Tim Bunce wrote:

Drivers should rarely if ever print anything below trace level 3.
Quite a few drivers get this wrong and it can be quite annoying to
the users to have to wade through lots of driver output when all
they want is the basic DBI level 1 or 2 trace.  Use levels around
4 through 7 to add more (obscure) detail.

So, 4 for more informative stuff, and down through 7 to report, say, every function executed?

I believe dTHR is only needed for the old "5.005 threads", not the
new iThreads, and the DBI will no longer support the old 5.005 threads
so you can delete them all for your new driver.

Okay. Thanks for the tip.

Some databases, like Oracle, have what you could call a "server-side
prepare" so DBD::Oracle's prepare() method sends the statement to
the server and then asks the server to 'describe' it.

PostgreSQL 7.3 has a "server-side prepare" that I'd like to take advantage of, but I don't think it offers any way to then "describe" the prepared statement.

(Without that you'd need a full sql parser available on the client
side.  Even then you wouldn't know the TYPE of the database fields
without much more work.)

Yep, I'll steer *far* clear of that! :-)

That's the wrong question. The DBI spec actually makes no assumptions
about the syntax of the statements. But it does say that question marks
should be used for placeholders.

Thing is, users tend to get upset (quite reasonably) when a driver
interprets question marks that are inside comments as real placeholders.

I guess I've never seen users use comments in SQL they're passing to the DBI. I personally tend to use Perl comments.

Personally I'd agree with them that it's a driver, er, limitation
(so I'm not over-happy with DBD::ODBC ducking the issue, but I
understand that DBD::ODBC faces a much tougher issue here than most drivers).

Okay. Perhaps I'll leave it in, then. But if I decide not to use PostgreSQL 7.3's server-side prepare functionality, and I still need to parse statements for every execute, I think that I might then eliminate them from the query in dbd_preparse() so that dbd_st_execute() doesn't have to worry about them.

Why should dbd_st_execute have to "deal" with them? The whole string
should just be sent off to the server.

I believe that others have answered better than I. The short answer: no support for sever-side prepare up to now, so dbd_st_execute has to parse the statement again every time.

If it's possible for you to _realiably_ determine the number of
field at prepare() time, then you should do it. If not, then do it
on just the *first* execute().

Yeah, I'm not sure that I want to do that kind of parsing in dbd_preparse.

phs stands for placeholder structure. The structure (typedef) is declared
in one of the driver *.h files. There's one per placeholder and they're
store in the hash pointed to by imp_sth->all_params_hv. All that's done
by dbd_preparse() as it scans the statement string.

Thanks. With the help of some of the other replies (notably Jeff's), and careful examination of DBD::Pg's and DBD::ODBC's code, I think I'm starting to follow what's happening there.

Thanks again for the help, Tim!

Regards,

David

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