Re: DBD::PgSQL: More Queestions

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
david(at)wheeler(dot)net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org